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RFC 9182 
A YANG Network Data Model for Layer 3 VPNs 


Abstract 


As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for 
communication between customers and service providers, this document defines an L3VPN 
Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network 
(L3VPN) services within a service provider network. The model provides a network-centric view 
of L3VPN services. 


The L3NM is meant to be used by a network controller to derive the configuration information 
that will be sent to relevant network devices. The model can also facilitate communication 
between a service orchestrator and a network controller/orchestrator. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9182. 


Copyright Notice 
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reserved. 


Barguil, et al. Standards Track Page1 


RFC 9182 L3NM YANG Data Model February 2022 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


February 2022 


[RFC8299] defines a YANG Layer 3 Virtual Private Network Service Model (L3SM) that can be used 
for communication between customers and service providers. Such a model focuses on 
describing the customer view of the Virtual Private Network (VPN) services and provides an 
abstracted view of the customer's requested services. That approach limits the usage of the L3SM 


to the role of a customer service model (as per [RFC8309]). 
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This document defines a YANG module called the "L3VPN Network Model" (L3NM). The L3NM is 
aimed at providing a network-centric view of Layer 3 (L3) VPN services. This data model can be 
used to facilitate communication between the service orchestrator and the network controller/ 
orchestrator by allowing more network-centric information to be included. It enables such 
additional capabilities as resource management, or it serves as a multi-domain orchestration 
interface where logical resources (such as route targets or route distinguishers) must be 
coordinated. 


This document uses the common VPN YANG module defined in [RFC9181]. 


This document does not obsolete [RFC8299]. These two modules are used for similar objectives but 
with different scopes and views. 


The L3NM YANG module was initially built with a "prune and extend" approach, taking as a 
starting point the YANG module described in [RFC8299]. Nevertheless, the L3NM is not defined as 
an augment to the L3SM, because a specific structure is required to meet network-oriented L3 
needs. 


Some information captured in the L3SM can be passed by the orchestrator in the L3NM (e.g., 
customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies). Also, some 
information captured in the L3SM may be maintained locally within the orchestrator, which is in 
charge of maintaining the correlation between a customer view and its network instantiation. 
Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., 
capabilities) to drive VPN service order handling and thus the L3SM. 


Section 5.1 of [RFC8969] illustrates how the L3NM can be used within the network management 
automation architecture. 


The L3NM does not attempt to address all deployment cases, especially those where L3VPN 
connectivity is supported through the coordination of different VPNs in different underlying 
networks. More complex deployment scenarios involving the coordination of different VPN 
instances and different technologies to provide end-to-end VPN connectivity are addressed by 
complementary YANG modules, e.g., [TYANG-Composed-VPN]. 


The L3NM focuses on Layer 3 VPNs based on BGP Provider Edges (PEs) as described in [RFC4026], 
[RFC4110], and [RFC4364]; and Multicast VPNs as described in [RFC6037] and [RFC6513]. 


The YANG data model in this document conforms to the Network Management Datastore 
Architecture (NMDA) defined in [RFC8342]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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This document assumes that the reader is familiar with the contents of [RFC6241], [RFC7950], 
[RFC8299], [RFC8309], and [RFC8453] and uses the terminology defined in those documents. 


This document uses the term "network model" as defined in Section 2.1 of [RFC8969]. 
The meanings of the symbols in the tree diagrams are defined in [RFC8340]. 


This document makes use of the following terms: 


Layer 3 VPN Service Model (L3SM): A YANG data model that describes the service requirements 
of an L3VPN that interconnects a set of sites from the point of view of the customer. The 
customer service model does not provide details on the service provider network. The L3VPN 
customer service model is defined in [RFC8299]. 


Layer 3 VPN Network Model (L3NM): AYANG data model that describes a VPN service in the 
service provider network. It contains information on the service provider network and might 
include allocated resources. It can be used by network controllers to manage and control the 
VPN service configuration in the service provider network. The corresponding YANG module 
can be used by a service orchestrator to request a VPN service to a network controller. 


Service orchestrator: Afunctional entity that interacts with the customer of an L3VPN. The 
service orchestrator interacts with the customer using the L3SM. The service orchestrator is 
responsible for the Customer Edge to Provider Edge (CE-PE) attachment circuits, the PE 
selection, and requesting the VPN service to the network controller. 


Network orchestrator: Afunctional entity that is hierarchically intermediate between a service 
orchestrator and network controllers. A network orchestrator can manage one or several 
network controllers. 


Network controller: Afunctional entity responsible for the control and management of the 
service provider network. 


VPN node: An abstraction that represents a set of policies applied on a PE and belonging to a 
single VPN service. A VPN service involves one or more VPN nodes. As it is an abstraction, the 
network controller will decide how to implement a VPN node. For example, in a BGP-based 
VPN, a VPN node could typically be mapped to a Virtual Routing and Forwarding (VRF) 
instance. 


VPNnetworkaccess: An abstraction that represents the network interfaces that are associated 
with a given VPN node. Traffic coming from the VPN network access belongs to the VPN. The 
attachment circuits (bearers) between CEs and PEs are terminated in the VPN network access. 
Areference to the bearer is maintained to allow keeping the link between the L3SM and L3NM 
when both models are used in a given deployment. 


VPN site: AVPN customer's location that is connected to the service provider network via a CE- 
PE link, which can access at least one VPN [RFC4176]. 


VPN service provider: Aservice provider that offers VPN-related services [RFC4176]. 
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Service provider network: Anetwork that is able to provide VPN-related services. 


This document is aimed at modeling BGP PE-based VPNs in a service provider network, so the 
terms defined in [RFC4026] and [RFC4176] are used in this document as well. 


3. Acronyms and Abbreviations 


The following acronyms and abbreviations are used in this document: 


ACL Access Control List 

AS Autonomous System 

ASM . Any-Source Multicast 

ASN AS Number 

BFD Bidirectional Forwarding Detection 
BGP Border Gateway Protocol 

BSR Bootstrap Router 

CE Customer Edge 

CsC Carriers' Carriers 

IGMP Internet Group Management Protocol 
L3NM  L3VPN Network Model 

L3SM L3VPN Service Model 

L3VPN Layer 3 Virtual Private Network 
MLD Multicast Listener Discovery 

MSDP Multicast Source Discovery Protocol 
MVPN Multicast VPN 

NAT Network Address Translation 

OAM Operations, Administration, and Maintenance 
OSPF Open Shortest Path First 

PE Provider Edge 

PIM Protocol Independent Multicast 

Qos Quality of Service 

RD Route Distinguisher 


RP Rendezvous Point 
RT Route Target 
SA Security Association 


SSM Source-Specific Multicast 
VPN Virtual Private Network 
VRF Virtual Routing and Forwarding 


4. L3NM Reference Architecture 


Figure 1 depicts the reference architecture for the L3NM. The figure is an expansion of the 
architecture presented in Section 5 of [RFC8299]; it decomposes the box marked "orchestration" in 
that section into three separate functional components: service orchestration, network 
orchestration, and domain orchestration. 
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Although some deployments may choose to construct a monolithic orchestration component 
(covering both service and network matters), this document advocates for a clear separation 
between service and network orchestration components for the sake of better flexibility. Such a 
design adheres to the L3VPN reference architecture defined in Section 1.3 of [RFC4176]. This 
separation relies upon a dedicated communication interface between these components and 
appropriate YANG modules that reflect network-related information. Such information is hidden 
from customers. 


The intelligence for translating customer-facing information into network-centric information 
(and vice versa) is implementation specific. 


The terminology from [RFC8309] is used here to show the distinction between the customer 
service model, the service delivery model, the network configuration model, and the device 
configuration model. In that context, the "domain orchestration" and "config manager" roles may 
be performed by "controllers". 
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| Customer 
4------- 4------- + 
Customer Service Model | 
(e.g., '13vpn-svc') | 
T 


------- +-------+ 
| Service | 
| Orchestration | 
+------- +------- + 
Service Delivery Model | 
'l3vpn-ntw' | 
R------- R------- + 
| Network | 
| Orchestration | 
+------- +------- + 
Network Configuration Model | 
4R----------- +----------- + 
| | 
R-------- +------ + +-------- +------ + 
| Domain | | Domain | 
| Orchestration | | Orchestration | 
+---+----------- + +-------- +------ + 
Device | | | 
Configuration | | | 
Model | | | 
+----+----+ | 
| Config | | | 
| Manager | | | 
+----+----+ | 
| | | 
I NETON EAA a TT Dr 
| | | 
+------------------------------------------------ + 
Network 


NETCONF: Network Configuration Protocol 
CLI: Command-Line Interface 


Figure 1: L3NM Reference Architecture 


The customer may use a variety of means to request a service that may trigger the instantiation 
of an L3NM. The customer may use the L3SM or more abstract models to request a service that 
relies upon an L3VPN service. For example, the customer may supply an IP Connectivity 
Provisioning Profile (CPP) that characterizes the requested service [RFC7297], an enhanced VPN 
(VPN+) service [Enhanced-VPN-Framework], or an IETF network slice service [Network-Slices- 
Framework]. 


Note also that both the L3SM and the L3NM may be used in the context of the Abstraction and 
Control of TE Networks (ACTN) framework [RFC8453]. Figure 2 shows the Customer Network 
Controller (CNC), the Multi-Domain Service Coordinator (MDSC), the Provisioning Network 
Controller (PNC) components, and the interfaces where the L3SM and L3NM are used. 
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+---------------------------------- + 
| Customer | 
| Site oo SS Se ease eee eee aes + | 
| | CNC el 
| Spee Ses aa ee ee eee + | 
4----4----------------------- +----- + 
| | 
| L3SM | L3SM 
| | 
+--------- +--------- + +--------- +--------- + 
| MDSC | | MDSC | 
| -aseeieeseieseseieseseiei ap | l (parent) l 
l Service | | T--------- +--------- + 
| | Orchestration | | | 
| +------- 4------- +] | L3NM 
| | | | 
| | L3NM l +--------- +--------- + 
| | | | MDSC 
| t------- 4------- * | l (child) 
| | Network | | 4R--------- +--------- + 
| | Orchestration | | | 
eee ees + | | 
4R--------- 4--------- + 
| | 
| Network Configuration | 
| | 
4------------ 4------- + +--------- +------------ + 
| Domain | | Domain | 
| Controller | | Controller | 
| dece cer aD. |: PXeseegcenr + | 
| ae | | | PNC | | 
| epo me ar | ce: i | 
4------------ 4------- + +--------- +------------ + 
| | 
| Device Configuration | 
| | 
+----+---+ +----+---+ 
| Device | | Device | 
+-------- + +-------- + 


Figure 2: L3SM and L3NM in the Context ofthe ACTN 


5. Relationship to Other YANG Data Models 


The "ietf-vpn-common" module [RFC9181] includes a set of identities, types, and groupings that 
are meant to be reused by VPN-related YANG modules independently of the layer (e.g., Layer 2, 
Layer 3) and the type of the module (e.g., network model, service model), including future 
revisions of existing models (e.g., [RFC8299] or [RFC8466]). The L3NM reuses these common types 
and groupings. 


In order to avoid data duplication and to ease passing data between layers when required 
(service layer to network layer and vice versa), early versions of the L3NM reused many of the 
data nodes that are defined in [RFC8299]. Nevertheless, that approach was abandoned in favor of 
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the "ietf-vpn-common" module because that initial design was interpreted as if the deployment of 
the L3NM depends on the L3SM, while this is not the case. For example, a service provider may 
decide to use the L3NM to build its L3VPN services without exposing the L3SM. 


As discussed in Section 4, the L3NM is meant to manage L3VPN services within a service provider 
network. The module provides a network view of the service. Such a view is only visible within the 
service provider and is not exposed outside (to customers, for example). The items below discuss 
how the L3NM interfaces with other YANG modules: 


L3SM: TheL3NM is not a customer service model. 


The internal view of the service (i.e., the L3NM) may be mapped to an external view that is 
visible to customers: the L3VPN Service Model (L3SM) [RFC8299]. 


The L3NM can be fed with inputs that are requested by customers. Such requests typically rely 
upon an L3SM template. Concretely, some parts of the L3SM module can be directly mapped to 
the L3NM, while other parts are generated as a function of the requested service and local 
guidelines. Some other parts are local to the service provider and do not map directly to the 
L3SM. 


Note that using the L3NM within a service provider does not assume, nor does it preclude, 
exposing the VPN service via the L3SM. This is deployment specific. Nevertheless, the design of 
the L3NM tries to align as much as possible with the features supported by the L3SM to ease the 
grafting of both the L3NM and the L3SM for the sake of highly automated VPN service 
provisioning and delivery. 


Network Topology Modules: An L3VPN involves nodes that are part of a topology managed by 
the service provider network. The topology can be represented using the network topology 
YANG module defined in [RFC8345] or its extension, such as a network YANG module for 
Service Attachment Points (SAPs) [YANG-SAPs]. 


Device Modules: The L3NM is not a device model. 


Once a global VPN service is captured by means of the L3NM, the actual activation and 
provisioning of the VPN service will involve a variety of device modules to tweak the required 
functions for the delivery of the service. These functions are supported by the VPN nodes and 
can be managed using device YANG modules. A non-comprehensive list of such device YANG 
modules is provided below: 


* Routing management [RFC8349]. 
* BGP [BGP-YANG]. 

* PIM [PIM-YANG]. 

* NAT management [RFC8512]. 

* QoS management [QoS-YANG]. 

* ACLs [RFC8519]. 


How the L3NM is used to derive device-specific actions is implementation specific. 
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6. Sample Uses of the L3NM Data Model 


This section provides a non-exhaustive list of examples that illustrate contexts where the L32NM 
can be used. 


6.1. Enterprise Layer 3 VPN Services 


Enterprise L3VPNs are one of the most demanded services for carriers; therefore, L3NM can be 
useful for automating the provisioning and maintenance of these VPNs. Templates and batch 
processes can be built, and as a result many parameters are needed for the creation from scratch 
of a VPN that can be abstracted to the upper Software-Defined Networking (SDN) layer [RFC7149] 
[RFC7426], but some manual intervention will still be required. 


A common function that is supported by VPNs is the addition or removal of VPN nodes. 
Workflows can use the L3NM in these scenarios to add or prune nodes from the network data 
model as required. 


6.2. Multi-Domain Resource Management 


The implementation of L3VPN services that span administratively separated domains (i.e. that 
are under the administration of different management systems or controllers) requires some 
network resources to be synchronized between systems. Particularly, resources must be 
adequately managed in each domain to avoid broken configurations. 


For example, route targets (RTs) shall be synchronized between PEs. When all PEs are controlled 
by the same management system, RT allocation can be performed by that management system. 
In cases where the service spans multiple management systems, the task of allocating RTs has to 
be aligned across the domains; therefore, the network model must provide a way to specify RTs. 
In addition, route distinguishers (RDs) must also be synchronized to avoid collisions of RD 
allocations between separate management systems. An incorrect allocation might lead to the 
same RD and IP prefixes being exported by different PEs. 


6.3. Management of Multicast Services 


Multicast services over L3VPNs can be implemented using dual PIM MVPNs (also known as the 
draft-rosen model) [RFC6037] or MVPNs based on Multiprotocol BGP (MP-BGP) [RFC6513] 
[RFC6514]. Both methods are supported and equally effective, but the main difference is that MP- 
BGP-based MVPNs do not require multicast configuration on the service provider network. MP- 
BGP MVPNs employ the intra-AS BGP control plane and PIM Sparse Mode [RFC7761] as the data 
plane. The PIM state information is maintained between PEs using the same architecture that is 
used for unicast VPNs. 


On the other hand, [RFC6037] has limitations, such as reduced options for transport, control plane 
scalability, availability, operational inconsistency, and the need to maintain state in the 
backbone. Because of these limitations, MP-BGP MVPNs provide the architectural model that has 
been taken as the base for implementing multicast services in L3VPNs. In this scenario, BGP is 
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used to autodiscover MVPN PE members and the customer PIM signaling is sent across the 
provider's core through MP-BGP. The multicast traffic is transported on MPLS Point-to-Multipoint 
(P2MP) Label Switched Paths (LSPs). 


7. Description of the L3NM YANG Module 


The L3NM ("ietf-IBvpn-ntw") is defined to manage L3VPNs in a service provider network. In 
particular, the "ietf-IBvpn-ntw" module can be used to create, modify, and retrieve L3VPN services 
of a network. 


The full tree diagram of the module can be generated using the "pyang" tool [PYANG]. That tree is 
not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided 
for the reader's convenience. 


7.1. Overall Structure of the Module 


The "ietf-I3vpn-ntw" module uses two main containers: 'vpn-profiles' and 'vpn-services' (see 
Figure 3). 


The 'vpn-profiles' container is used by the provider to maintain a set of common VPN profiles 
that apply to one or several VPN services (Section 7.2). 


The 'vpn-services' container maintains the set of VPN services managed within the service 
provider network. The 'vpn-service' is the data structure that abstracts a VPN service (Section 7.3). 


module: ietf-13vpn-ntw 
+--rw l3vpn-ntw 
*--rw vpn-profiles 


+--rw vpn-services 
*--rw vpn-service* [vpn-id] 


*--rw vpn-nodes 


*--rw vpn-node* [vpn-node-id] 


*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


Figure 3: Overall L3NM Tree Structure 


Some of the data nodes are keyed by the address family. For the sake of data representation 
compactness, it is RECOMMENDED to use the dual-stack address family for data nodes that have 
the same value for both IPv4 and IPv6. If, for some reason, a data node is present for both dual- 
stack and IPv4 (or IPv6), the value that is indicated under dual-stack takes precedence over the 
value that is indicated under IPv4 (or IPv6). 
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7.2. VPN Profiles 


The 'vpn-profiles' container (Figure 4) allows the VPN service provider to define and maintain a 
set of VPN profiles [RFC9181] that apply to one or several VPN services. 


+--rw l3vpn-ntw 
*--rw vpn-profiles 
| -*--rw valid-provider-identifiers 
*--rw external-connectivity-identifier* [id] 
| {external-connectivity}? 


| 

| 

| | +--rw id string 

| +--rw encryption-profile-identifier* [id] 
| | +--rw id string 

| +--rw qos-profile-identifier* [id] 

l | +--rw id string 

| +--rw bfd-profile-identifier* [id] 

| | +--rw id string 

| +--rw forwarding-profile-identifier* [id] 
| | +--rw id string 

| +--rw routing-profile-identifier* [id] 

| +--rw id string 

+ 


--rw vpn-services 


Figure 4: VPN Profiles Subtree Structure 


This document does not make any assumption about the exact definition of these profiles. The 
exact definition of the profiles is local to each VPN service provider. The model only includes an 
identifier for these profiles in order to facilitate identifying and binding local policies when 
building a VPN service. As shown in Figure 4, the following identifiers can be included: 


'external-connectivity-identifier: This identifier refers to a profile that defines the external 
connectivity provided to a VPN service (or a subset of VPN sites). External connectivity may 
be access to the Internet or restricted connectivity, such as access to a public/private cloud. 


'encryption-profile-identifier: An encryption profile refers to a set of policies related to the 
encryption schemes and setup that can be applied when building and offering a VPN service. 


'qos-profile-identifier: A Quality of Service (QoS) profile refers to a set of policies, such as 
classification, marking, and actions (e.g., [RFC3644]). 


‘bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD 
policies [RFC5880] that can be invoked when building a VPN service. 


'forwarding-profile-identifier: Aforwarding profile refers to the policies that apply to the 
forwarding of packets conveyed within a VPN. Such policies may consist, for example, of 
applying Access Control Lists (ACLs). 
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'routing-profile-identifier: A routing profile refers to a set of routing policies that will be invoked 


(e.g., BGP policies) when delivering the VPN service. 


7.3. VPN Services 


The 'vpn-service' is the data structure that abstracts a VPN service in the service provider 
network. Each 'vpn-service' is uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only 
meaningful locally (e.g. the network controller). The subtree of the 'vpn-services' is shown in 


Figure 5. 


*--rw l3vpn-ntw 
*--rw vpn-profiles 
+--rw vpn-services 
*--rw vpn-service* [vpn-id] 


+--rw vpn-id vpn-common:vpn-id 
+--rw vpn-name? string 

+--rw vpn-description? string 

+--rw customer-name? string 

+--rw parent-service-id? vpn-common:vpn-id 
+--rw vpn-type? identityref 

+--rw vpn-service-topology? identityref 


+--rw status 
| -*--rw admin-status 
| +--rw status? identityref 


*--ro oper-status 
+--ro status? identityref 


--rw vpn-instance-profiles 


--rw underlay-transport 
*-- (type)? 
*--:(abstract) 
| -*--rw transport-instance-id? 
| *--rw instance-type? 
*--:(protocol) 
*--rw protocol* 
+--rw external-connectivity 


| 
| 
| 
| 
| 
T 
| 
T 
| 
| 
| 
| 
| 
| 


| (vpn-common:external-connectivity)? 


| *--rw (profile)? 

| +--:(profile) 

| +--rw profile-name? 
+--rw vpn-nodes 


Figure 5: VPN Services Subtree Structure 


| +--rw last-change? yang:date-and-time 


+--ro last-change? yang:date-and-time 


identityref 


identityref 


The descriptions of the VPN service data nodes that are depicted in Figure 5 are as follows: 


‘vpn-id': An identifier that is used to uniquely identify the L3VPN service within the L3NM scope. 
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‘vpn-name': Associates a name with the service in order to facilitate the identification of the 
service. 


'vpn-description: Includes a textual description of the service. 
The internal structure of a VPN description is local to each VPN service provider. 


‘customer-name': Indicates the name of the customer who ordered the service. 


‘parent-service-id': Refers to an identifier of the parent service (e.g., L3SM, IETF network slice, 
VPN?) that triggered the creation of the VPN service. This identifier is used to easily correlate 
the (network) service as built in the network with a service order. A controller can use that 
correlation to enrich or populate some fields (e.g., description fields) as a function of local 
deployments. 


‘vpn-type': Indicates the VPN type. The values are taken from [RFC9181]. For the L3NM, this is 
typically set to "BGP/MPLS L3VPN", but other values may be defined to support specific Layer 3 
VPN capabilities (e.g., [RFC9136]). 


'vpn-service-topology': Indicates the network topology for the service: 'hub-spoke', 'any-to-any', 
or 'custom'. The network implementation of this attribute is defined by the correct usage of 
import and export targets (Section 4.3.5 of [RFC4364]). 


'status: Used to track the service status of a given VPN service. Both operational status and 
administrative status are maintained together with a timestamp. For example, a service can 
be created but not put into effect. 


Administrative status and operational status can be used as a trigger to detect service 
anomalies. For example, a service that is declared active at the service layer but is still inactive 
at the network layer may be an indication that network provision actions are needed to align 
the observed service status with the expected service status. 


'vpn-instance-profiles': Defines reusable parameters for the same 'vpn-service'. 
More details are provided in Section 7.4. 


‘underlay-transport': Describes the preference for the transport technology to carry the traffic 
of the VPN service. This preference is especially useful in networks with multiple domains and 
Network-to-Network Interface (NNI) types. The underlay transport can be expressed as an 
abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, 
or a network slice name) or as an ordered list of the actual protocols to be enabled in the 
network. 


A rich set of protocol identifiers that can be used to refer to an underlay transport are defined 
in [RFC9181]. 


‘external-connectivity': Indicates whether/how external connectivity is provided to the VPN 
service. For example, a service provider may provide external connectivity to a VPN customer 
(e.g., to a public cloud). Such a service may involve tweaking both filtering and NAT rules (e.g., 
binding a Virtual Routing and Forwarding (VRF) interface with a NAT instance as discussed in 
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Section 2.10 of [RFC8512]). These value-added features may be bound to all, or a subset of, 
network accesses. Some of these value-added features may be implemented in a PE or in nodes 
other than PEs (e.g., a P node or even a dedicated node that hosts the NAT function). 


Only a pointer to a local profile that defines the external-connectivity feature is supported in 
this document. 


‘vpn-node': An abstraction that represents a set of policies applied to a network node and 
belonging to a single 'vpn-service'. A VPN service is typically built by adding instances of 'vpn- 
node' to the 'vpn-nodes' container. 


A'vpn-node' contains 'vpn-network-accesses', which are the interfaces attached to the VPN by 
which the customer traffic is received. Therefore, the customer sites are connected to the 'vpn- 
network-accesses'. 


Note that because this is a network data model, information about customers' sites is not 
required in the model. Rather, such information is relevant in the L3SM. Whether that 
information is included in the L3NM, e.g., to populate the various 'description' data nodes, is 
implementation specific. 


More details are provided in Section 7.5. 


7.4. VPN Instance Profiles 


VPN instance profiles are meant to factorize data nodes that are used at many levels of the 
model. Generic VPN instance profiles are defined at the VPN service level and then called at the 
VPN node and VPN network access levels. Each VPN instance profile is identified by 'profile-id'. 
This identifier is then referenced for one or multiple VPN nodes (Section 7.5) so that the controller 
can identify generic resources (e.g., RTs and RDs) to be configured for a given VRF instance. 


The subtree of the 'vpn-instance-profiles' is shown in Figure 6. 
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+--rw l3vpn-ntw 
*--rw vpn-profiles 
+--rw vpn-services 
*--rw vpn-service* [vpn-id] 
+--rw vpn-id vpn-common:vpn-id 


+--rw vpn-instance-profiles 
+--rw vpn-instance-profile* [profile-id] 


+--rw profile-id string 
+--rw role? identityref 
+--rw local-as? inet :as-number 


| {vpn-common:rtg-bgp}? 
+--rw (rd-choice)? 
| +--:(directly-assigned) 
| +--rw rd? 
| rt-types:route-distinguisher 
*--:(directly-assigned-suffix) 
| *--rw rd-suffix? uint16 
*--:(auto-assigned) 
| -*--rw rd-auto 
| *--rw (auto-mode)? 
| | *--:(from-pool) 
| | | +--rw rd-pool-name? string 
l | +--:(full-auto) 
| | +--rw auto? empty 
| *--ro auto-assigned-rd? 
| rt-types:route-distinguisher 
*--:(auto-assigned-suffix) 
| +--rw rd-auto-suffix 
| +--rw (auto-mode)? 
| | +--:(from-pool) 
| 
| 
| 
| 
+-- 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| +--rw no-rd? empty 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
T 


| | ---rw rd-pool-name? string 
| *--:(full-auto) 
| +--rw auto? empty 
*--ro auto-assigned-rd-suffix? uint16 
:(no-rd) 
--rw address-family* [address-family] 
*--rw address-family identityref 
*--rw vpn-targets 
| -*--rw vpn-target* [id] 
| | -*--rw id uint8 
| | ---rw route-targets* [route-target] 
| | | +--rw route-target 
ISI rt-types:route-target 
| | ---rw route-target-type 
4 rt-types:route-target-type 
| +--rw vpn-policies 
| *--rw import-policy? string 
| *--rw export-policy? string 
*--rw maximum-routes* [protocol] 
*--rw protocol identityref 
+--rw maximum-routes? uint32 
--rw multicast {vpn-common:multicast}? 
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Figure 6: Subtree Structure of VPN Instance Profiles 


The descriptions of the listed data nodes are as follows: 


'profile-id Used to uniquely identify a VPN instance profile. 


'role: Indicates the role of the VPN instance profile in the VPN. Role values are defined in 
[RFC9181] (e.g., 'any-to-any-role’, 'spoke-role’, 'hub-role"). 


‘local-as': Indicates the Autonomous System Number (ASN) that is configured for the VPN node. 


'rd': As defined in [RFC9181], the following RD assignment modes are supported: direct 
assignment, full automatic assignment, automatic assignment from a given pool, and no 
assignment. For illustration purposes, the following modes can be used in the deployment 
cases: 


'directly-assigned': The VPN service provider (service orchestrator) assigns RDs explicitly. 
This case will fit with a brownfield scenario where some existing services need to be 
updated by the VPN service provider. 


‘full-auto': The network controller auto-assigns RDs. This can apply for the deployment of 
new services. 


‘no-rd': The VPN service provider (service orchestrator) explicitly wants no RD to be 
assigned. This case can be used for CE testing within the network or for troubleshooting 
proposes. 


Also, the module accommodates deployments where only the Assigned Number subfield of 
RDs (Section 4.2 of [RFC4364]) is assigned from a pool while the Administrator subfield is set to, 
for example, the Router ID that is assigned to a VPN node. The module supports these modes 
for managing the Assigned Number subfield: explicit assignment, auto-assignment from a 
pool, and full auto-assignment. 


‘address-family': Includes a set of data nodes per address family: 
'address-family: Identifies the address family. It can be set to 'ipv4’, 'ipv6', or 'dual-stack'. 
‘vpn-targets': Specifies RT import/export rules for the VPN service (Section 4.3 of [RFC4364]). 


'maximum-routes: Indicates the maximum number of prefixes that the VPN node can 
accept for a given routing protocol. If ‘protocol’ is set to 'any', this means that the 
maximum value applies to each active routing protocol. 


‘multicast': Enables multicast traffic in the VPN service. Refer to Section 7.7. 


7.5. VPN Nodes 


The 'vpn-node' is an abstraction that represents a set of common policies applied on a given 
network node (typically, a PE) and belonging to one L3VPN service. The 'vpn-node' includes a 
parameter to indicate the network node on which it is applied. In the case that the 'ne-id' points to 
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a specific PE, the 'vpn-node' will likely be mapped to a VRF instance in the node. However, the 
model also allows pointing to an abstract node. In this case, the network controller will decide 
how to split the 'vpn-node' into VRF instances. 


The VPN node subtree structure is shown in Figure 7. 
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+--rw l3vpn-ntw 

*--rw vpn-profiles 
+--rw vpn-services 

*--rw vpn-service* [vpn-id] 


t--rW vpn-nodes 
*--rw vpn-node* [vpn-node-id] 


*--rw vpn-node-id vpn-common: vpn- id 
*--rw description? string 

+--rw ne-id? string 

*--rw local-as? inet:as-number 

| {vpn-common:rtg-bgp}? 

+--rw router-id? rt-types:router-id 


+--rw active-vpn-instance-profiles 
| -*--rw vpn-instance-profile* [profile-id] 


*--rw profile-id leafref 
*--rw router-id* [address-family] 

| -*--rw address-family identityref 

| +--rw router-id? inet:ip-address 
*--rw local-as? inet:as-number 


| {vpn-common:rtg-bgp}? 

+--rw (rd-choice)? 

[PAS 

*--rw address-family* [address-family] 

| -*--rw address-family identityref 
Ire dae e 

| -*--rw vpn-targets 

(fies Dee 

| +--rw maximum-routes* [protocol] 

| Ar 

*--rw multicast {vpn-common:multicast}? 


-rw msdp {msdp}? 


+--rw peer? inet:ipv4-address 
*--rw local-address? inet:ipv4-address 
= eWisSicd Gus 
+--rw admin-status 
| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
*--ro oper-status 
*--ro status? identityref 
+--ro last-change? yang:date-and-time 
--rw groups 
*--rw group* [group-id] 
*--rw group-id string 
--rw status 
*--rw admin-status 
| +--rw status? identityref 


| -*--rw last-change? yang:date-and-time 
*--ro oper-status 
*--ro status? identityref 
+--ro last-change? yang:date-and-time 
--rw vpn-network-accesses 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
T 
| 
| 
| 
| 
| 
| 
| 
| 
| 
T 
| 
| 
T 
| 
| 
| 
| 
| 
| 
+ 
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Figure 7: VPN Node Subtree Structure 


The descriptions of the 'vpn-node' data nodes (Figure 7) are as follows: 


‘vpn-node-id': An identifier that uniquely identifies a node that enables a VPN network access. 
'description: Provides a textual description of the VPN node. 

‘ne-id': Includes a unique identifier of the network element where the VPN node is deployed. 
locabas': Indicates the ASN that is configured for the VPN node. 

‘router-id': Indicates a 32-bit number that is used to uniquely identify a router within an AS. 


'active-vpn-instance-profiles: Lists the set of active VPN instance profiles for this VPN node. 
Concretely, one or more VPN instance profiles that are defined at the VPN service level can be 
enabled at the VPN node level; each of these profiles is uniquely identified by means of 'profile- 
id'. The structure of 'active-vpn-instance-profiles' is the same as the structure discussed in 
Section 7.4, except that the structure of 'active-vpn-instance-profiles' includes 'router-id' but 
does not include the 'role' leaf. The value of 'router-id' indicated under 'active-vpn-instance- 
profiles' takes precedence over the 'router-id' under the 'vpn-node' for the indicated address 
family. For example, Router IDs can be configured per address family. This capability can be 
used, for example, to configure an IPv6 address as a Router ID when such a capability is 
supported by involved routers. 


Values defined in 'active-vpn-instance-profiles' override the values defined at the VPN service 
level. An example is shown in Appendix A.3. 


'msdp: For redundancy purposes, the Multicast Source Discovery Protocol (MSDP) [RFC3618] 
may be enabled and used to share state information about sources between multiple 
Rendezvous Points (RPs). The purpose of MSDP in this context is to enhance the robustness of 
the multicast service. MSDP may be configured on non-RP routers; this is useful in a domain 
that does not support multicast sources but does support multicast transit. 


‘groups': Lists the groups to which a VPN node belongs [RFC9181]. For example, the 'group-id' is 
used to associate redundancy or protection constraints with VPN nodes. 


'status: Tracks the status of a node involved in a VPN service. Both operational status and 
administrative status are maintained. A mismatch between the administrative status vs. the 
operational status can be used as a trigger to detect anomalies. 


‘vpn-network-accesses': Represents the point to which sites are connected. 


Note that unlike the L3SM, the L3NM does not need to model the customer site -- only the 
points that receive traffic from the site (i.e., the PE side of Provider Edge to Customer Edge (PE- 
CE) connections). Hence, the VPN network access contains the connectivity information 
between the provider's network and the customer premises. The VPN profiles (‘vpn-profiles') 
have a set of routing policies that can be applied during the service creation. 


See Section 7.6 for more details. 
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7.6. VPN Network Accesses 


The 'vpn-network-access' includes a set of data nodes that describe the access information for the 
traffic that belongs to a particular L3VPN (Figure 8). 


t--rW vpn-nodes 
*--rw vpn-node* [vpn-node-id] 


*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


*--rw id vpn-common:vpn-id 
+--rw interface-id? string 

+--rw description? string 

+--rw vpn-network-access-type? identityref 

+--rw vpn-instance-profile? leafref 


+--rw status 

| -*--rw admin-status 
| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
*--ro oper-status 


+--ro status? identityref 
--rw connection 


| 
| 
| 
| 
| *--ro last-change? yang:date-and-time 
T 


Mem 
+--rw ip-connection 
| 


*--rw routing-protocols 


*t--rw oam 
Is 


+--rw security 


+--rw service 


Figure 8: VPN Network Access Subtree Structure 


A'vpn-network-access' (Figure 8) includes the following data nodes: 


‘id': An identifier of the VPN network access. 


‘interface-id': Indicates the physical or logical interface on which the VPN network access is 
bound. 


‘description’: Includes a textual description of the VPN network access. 


'Vpn-network-access-type': Used to select the type of network interface to be deployed in the 
devices. The available defined values are as follows: 


‘point-to-point’: 
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Represents a direct connection between the endpoints. The controller must keep the 
association between a logical or physical interface on the device with the 'id' of the 'vpn- 
network-access'. 


'multipoint: Represents a multipoint connection between the customer site and the PEs. The 
controller must keep the association between a logical or physical interface on the device 
with the 'id' of the 'vpn-network-access'. 


‘irb': Represents a connection coming from an L2VPN service. An identifier of such a service 
(12vpn-id") may be included in the 'connection' container, as depicted in Figure 9 (Section 
7.6.1). The controller must keep the relationship between the logical tunnels or bridges on 
the devices with the 'id' of the vpn-network-access'. 


‘loopback': Represents the creation of a logical interface on a device. An example that 
illustrates how a loopback interface can be used in the L3NM is provided in Appendix A.2. 


'vpn-Hnstance-profile: Provides a pointer to an active VPN instance profile at the VPN node 
level. Referencing an active VPN instance profile implies that all associated data nodes will be 
inherited by the VPN network access. However, some inherited data nodes (e.g., multicast) can 
be overridden at the VPN network access level. In such a case, adjusted values take precedence 
over inherited values. 


'status: Indicates both operational status and administrative status of a VPN network access. 


'connection: Represents and groups the set of Layer 2 connectivity from where the traffic of the 
L3VPN in a particular VPN network access is coming. See Section 7.6.1. 


'ipconnection: Contains Layer 3 connectivity information on a VPN network access (e.g., IP 
addressing). See Section 7.6.2. 


‘routing-protocols': Includes the CE-PE routing configuration information. See Section 7.6.3. 


‘oam': Specifies the Operations, Administration, and Maintenance (OAM) mechanisms used for 
a VPN network access. See Section 7.6.4. 


'security: Specifies the authentication and the encryption to be applied for a given VPN network 
access. See Section 7.6.5. 


‘service’: Specifies the service parameters (e.g., QoS, multicast) to apply for a given VPN network 
access. See Section 7.6.6. 


7.6.1. Connection 


The 'connection' container represents the Layer 2 connectivity to the L3VPN for a particular VPN 
network access. As shown in the tree depicted in Figure 9, the ‘connection’ container defines 
protocols and parameters to enable such connectivity at Layer 2. 


The traffic can enter the VPN with or without encapsulation (e.g., VLAN, QinQ). The 
‘encapsulation’ container specifies the Layer 2 encapsulation to use (if any) and allows the 
configuration of the relevant tags. 
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The interface that is attached to the L3VPN is identified by the 'interface-id' at the vpn-network- 
access' level. From a network model perspective, it is expected that the 'interface-id' is sufficient 
to identify the interface. However, specific Layer 2 sub-interfaces may be required to be 
configured in some implementations/deployments. Such a Layer-2-specific interface can be 
included in 12-termination-point'. 


If a Layer 2 tunnel is needed to terminate the service in the CE-PE connection, the 12-tunnel- 
service' container is used to specify the required parameters to set such a tunneling service (e.g., a 
Virtual Private LAN Service (VPLS) or a Virtual eXtensible Local Area Network (VXLAN)). An 
identity called 12-tunnel-type' is defined for Layer 2 tunnel selection. The container can also 
identify the pseudowire (Section 6.1 of [RFC8077]). 


As discussed in Section 7.6, 'I2vpn-id' is used to identify the L2VPN service that is associated with 
an Integrated Routing and Bridging (IRB) interface. 


To accommodate implementations that require internal bridging, a local bridge reference can be 
specified in 'local-bridge-reference'. Such a reference may be a local bridge domain. 


A site, as per [RFC4176], represents a VPN customer's location that is connected to the service 
provider network via a CE-PE link, which can access at least one VPN. The connection from the 
site to the service provider network is the bearer. Every site is associated with a list of bearers. A 
bearer is the Layer 2 connection with the site. In the L3NM, it is assumed that the bearer has been 
allocated by the service provider at the service orchestration stage. The bearer is associated with 
a network element and a port. Hence, a bearer is just a 'bearer-reference' to allow the association 
between a service request (e.g., the L3SM) and the L3NM. 


The L3NM can be used to create a Link Aggregation Group (LAG) interface for a given L3VPN 
service (‘lag-interface') [TEEE802.1AX]. Such a LAG interface can be referenced under 'interface-id' 
(Section 7.6). 
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+--rw connection 

*--rw encapsulation 

| -*--rw type? identityref 
| -*--rw dotiq 

| | -*--rw tag-type? identityref 
| | +--rw cvlan-id? uint16 

| -*--rw priority-tagged 

| | +--rw tag-type? identityref 
| +--rw qinq 

| +--rw tag-type? identityref 
| +--rw svlan-id uint16 

| +--rw cvlan-id uint16 
*--rw (12-service)? 

| +--:(12-tunnel-service) 

| | ---rw 12-tunnel-service 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


*--rw type? identityref 
*--rw pseudowire 
| +--rw vcid? uint32 


| -*--rw far-end? union 
*--rw vpls 


| 

| 

| 

| 

| 

| 

| 

| +--rw vxlan 
| 

| 

| 
+-- 


| +--rw void? uint32 
| +--rw far-end* union 
+--rw vni-id uint32 
+--rw peer-mode? identityref 
+--rw peer-ip-address* inet:ip-address 
:(12vpn) 
l *--rw l2vpn-id? vpn-common:vpn-id 
+--rw 12-termination-point? string 
+--rw local-bridge-reference? string 
+--rw bearer-reference? string 


| (vpn-common:bearer-reference)? 
+--rw lag-interface {vpn-common:lag-interface}? 
+--rw lag-interface-id? string 
*--rw member-link-list 
+--rw member-link* [name] 
+--rw name string 


Figure 9: Connection Subtree Structure 


7.6.2. IP Connection 


This container is used to group Layer 3 connectivity information, particularly the IP addressing 
information, of a VPN network access. The allocated address represents the PE interface address 
configuration. Note that a distinct Layer 3 interface other than the interface indicated under the 
‘connection’ container may be needed to terminate the Layer 3 service. The identifier of such an 
interface is included in '13-termination-point'. For example, this data node can be used to carry 
the identifier of a bridge domain interface. 


As shown in Figure 10, the 'ip-connection' container can include IPV4, IPv6, or both if dual-stack is 
enabled. 
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*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


+--rw ip-connection 
| +--rw 13-termination-point? string 
| +--rw ipv4 {vpn-common:ipv4}? 

eee 
| 
| 


+--rw ipv6 {vpn-common:ipv6}? 


Figure 10: IP Connection Subtree Structure 


For both IPv4 and IPv6, the IP connection supports three IP address assignment modes for 
customer addresses: provider DHCP, DHCP relay, and static addressing. Note that for the IPv6 case, 
Stateless Address Autoconfiguration (SLAAC) [RFC4862] can be used. For both IPv4 and IPv6, 


'address-allocation-type' is used to indicate the IP address allocation mode to activate for a given 
VPN network access. 


When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally 
or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'. 


Figure 11 shows the structure of the dynamic IPv4 address assignment (i.e., by means of DHCP). 
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L3NM YANG Data Model 
ip-connection 
rw 13-termination-point? string 
rw ipv4 {vpn-common:ipv4}? 
+--rw local-address? inet:ipv4-address 
+--rw prefix-length? uint8 


+--rw address-allocation-type? identityref 
*--rw (allocation-type)? 
*--:(provider-dhcp) 
| -*--rw dhcp-service-type? enumeration 
*--rw (service-type)? 
*--:(relay) 
| -*--rw server-ip-address* 
| inet:ipv4-address 
*--:(server) 
*--rw (address-assign)? 
*--:(number) 
| -*--rw number-of-dynamic-address? 
| uint16 
*--:(explicit) 
*--rw customer-addresses 
*--rw address-pool* [pool-id] 


*--rw pool-id string 
| inet:ipv4-address 
*--rw end-address? 
inet:ipv4-address 
--:(dhcp-relay) 
+--rw customer-dhcp-servers 
*--rw server-ip-address* inet:ipv4-address 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| +--rw start-address 
| 
| 
| 
+ 
| 
| 
+ 


--:(static-addresses) 


IP Connection Subtree Structure (IPv4) 


February 2022 


Figure 12 shows the structure of the dynamic IPv6 address assignment (i.e., DHCPv6 and/or 
SLAAC). Note that if 'address-allocation-type' is set to 'slaac', the Prefix Information option of 
Router Advertisements that will be issued for SLAAC purposes will carry the IPv6 prefix that is 


determined by 'local-address' and 'prefix-length'. For example, if local-address' is set to 
'2001:db8:0:1::1' and 'prefix-length' is set to '64', the IPv6 prefix that will be used is 


'2001:db8:0:1::/64'. 
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+--rw ip-connection 


*--rW 
+--rw 
*--rW 


*--rW 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| | 

| Ru 
| | 

| | 

| | 

| tas 
| 


*--rw 13-termination-point? string 
*--rw ipv4 {vpn-common:ipv4}? 


+--rw ipv6 {vpn-common:ipv6}? 


local-address? inet :ipv6-address 
prefix-length? uint8 
address-allocation-type? identityref 


(allocation-type)? 
*--:(provider-dhcp) 
*--rw provider-dhcp 


*--rw dhcp-service-type? 


| enumeration 
*--rw (service-type)? 
*--:(relay) 


| -*--rw server-ip-address* 
| inet:ipv6-address 
*--:(server) 
*--rw (address-assign)? 
*--:(number) 
| -*--rw number-of-dynamic-address? 
uint16 
+--: (explicit) 
+--rw customer-addresses 
*--rw address-pool* [pool-id] 
*--rw pool-id string 
*--rw start-address 
| inet:ipv6-address 
*--rw end-address? 
inet:ipv6-address 


:(dhcep-relay) 
+--rw customer-dhcp-servers 
+--rw server-ip-address* 


inet :ipv6-address 


:(static-addresses) 


Figure 12: IP Connection Subtree Structure (IPv6) 


February 2022 


In the case of static addressing (Figure 13), the model supports the assignment of several IP 
addresses in the same 'vpn-network-access'. To identify which of the addresses is the primary 
address of a connection, the 'primary-address' reference MUST be set with the corresponding 


'address-id'. 
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+--rw ip-connection 


*--rw 13-termination-point? string 
+--rw ipv4 {vpn-common:ipv4}? 
| -*--rw address-allocation-type? identityref 


*--rw (allocation-type)? 


*--:(static-addresses) 


| 

| 

| *--rw primary-address? -> ../address/address- id 
| +--rw address* [address-id] 

| +--rw address-id String 

| +--rw customer-address? inet:ipv4-address 

+--rw ipv6 {vpn-common:ipv6}? 


+--rw address-allocation-type? identityref 
+--rw (allocation-type)? 


+--:(static-addresses) 


+--rw primary-address? -> ../address/address-id 
+--rw address* [address-id] 
+--rw address-id string 


+--rw customer-address? inet:ipv6-address 


Figure 13: IP Connection Subtree Structure (Static Mode) 


7.6.3. CE-PE Routing Protocols 


A VPN service provider can configure one or more routing protocols associated with a particular 
'vpn-network-access'. Such routing protocols are enabled between the PE and the CE. Each 
instance is uniquely identified to accommodate scenarios where multiple instances of the same 
routing protocol have to be configured on the same link. 


The subtree of the routing-protocols' is shown in Figure 14. 
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+--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


*--rw routing-protocols 
*--rw routing-protocol* [id] 
*--rw id string 


*--rw type? identityref 
*--rw routing-profiles* [id] 
| *--rw id leafref 


| -*--rw type? identityref 
+--rw static 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| : 
| +--rw ospf 
| 

| 

| 

| 

| 

| 

| 

+ 


+--rw bgp 
I) eee 
lares 
*--rw isis 
i m 
E e 
== FW security 


Figure 14: Routing Subtree Structure 


Multiple routing instances can be defined, each uniquely identified by an 'id'. The type of routing 
instance is indicated in 'type'. The values of these attributes are those defined in [RFC9181] (the 
'routing-protocol-type' identity). 


Configuring multiple instances of the same routing protocol does not automatically imply that, 
from a device configuration perspective, there will be parallel instances (e.g., multiple processes) 
running on the PE-CE link. It is up to each implementation (typically, network orchestration, as 
shown in Figure 1) to decide on the appropriate configuration as a function of underlying 
capabilities and service provider operational guidelines. As an example, when multiple BGP peers 
need to be implemented, multiple instances of BGP must be configured as part of this model. 
However, from a device configuration point of view, this could be implemented as: 


* Multiple BGP processes with a single neighbor running in each process. 
* Asingle BGP process with multiple neighbors running. 
e A combination thereof. 


Routing configuration does not include low-level policies. Such policies are handled at the device 

configuration level. Local policies of a service provider (e.g., filtering) are implemented as part of 
the device configuration; these are not captured in the L3NM, but the model allows local profiles 

to be associated with routing instances (‘routing-profiles'). Note that these routing profiles can be 
scoped to capture parameters that are globally applied to all L3VPN services within a service 
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provider network, while customized L3VPN parameters are captured by means of the L3NM. The 
provisioning of an L3VPN service will thus rely upon the instantiation of these global routing 
profiles and the customized L3NM. 


7.6.3.1. Static Routing 


The L3NM supports the configuration of one or more IPv4/IPV6 static routes. Since the same 
structure is used for both IPv4 and IPv6, using one single container to group both static entries 
independently of their address family was considered at one time, but that design was 
abandoned to ease the mapping, using the structure provided in [RFC8299]. 


The static routing subtree structure is shown in Figure 15. 
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*--rw routing-protocols 
*--rw routing-protocol* [id] 


*--rw static 
*--rw cascaded-lan-prefixes 
*--rw ipv4-lan-prefixes* 
| [lan next-hop] 
{vpn-common:ipv4}? 


+--rw lan inet :ipv4-prefix 
+--rw lan-tag? string 

+--rw next-hop union 

+--rw bfd-enable? boolean 

+--rw metric? uint32 


| 

| 

| 

| 

| 

| 

| -*--rw preference? uint32 
| +--rw status 

l +--rw admin-status 
| 

| 

| 

| 

| 

+ 


| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
*--ro oper-status 
*--ro status? identityref 
+--ro last-change? yang:date-and-time 
--rw ipv6-lan-prefixes* 


[lan next-hop] 
{vpn-common:ipv6}? 


+--rw lan inet :ipv6-prefix 
+--rw lan-tag? string 

+--rw next-hop union 

+--rw bfd-enable? boolean 

+--rw metric? uint32 


+--rw preference? uint32 
+--rw status 
+--rw admin-status 
| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
*--ro oper-status 
+--ro status? identityref 
+--ro last-change? yang:date-and-time 


Figure 15: Static Routing Subtree Structure 


As depicted in Figure 15, the following data nodes can be defined for a given IP prefix: 


lan-tag: Indicates a local tag (e.g., "myfavorite-lan") that is used to enforce local policies. 


‘next-hop': Indicates the next hop to be used for the static route. It can be identified by an IP 
address, a predefined next-hop type (e.g., 'discard' or 'local-link’), etc. 


‘bfd-enable': Indicates whether BFD is enabled or disabled for this static route entry. 


"metric: Indicates the metric associated with the static route entry. This metric is used when the 
route is exported into an IGP. 
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'preference': Indicates the preference associated with the static route entry. This preference is 
used to select a preferred route among routes to the same destination prefix. 


'status: Used to convey the status of a static route entry. This data node can also be used to 
control the (de)activation of individual static route entries. 


7.6.3.2. BGP 

The L3NM allows the configuration of a BGP neighbor, including a set of parameters that are 
pertinent to be tweaked at the network level for service customization purposes. The 'bgp' 
container does not aim to include every BGP parameter; a comprehensive set of parameters 


belongs more to the BGP device model. 


The BGP routing subtree structure is shown in Figure 16. 
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*--rw routing-protocols 
*--rw routing-protocol* [id] 


+--rw bgp 
+--rw description? 
+--rw local-as? 
*--rw peer-as 
*--rw address-family? 
*--rw local-address? 
*--rw neighbor* 
*--rw multihop? 
+--rw as-override? 
*--rw allow-own-as? 
*--rw prepend-global-as? 
*--rw send-default-route? 
+--rw site-of-origin? 
*--rw ipv6-site-of-origin? 
+--rw redistribute-connecte 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| | -*--rw address-family 

| | +--rw enable? 

| +--rw bgp-max-prefix 

| | +--rw max-prefix? 

| | -*--rw warning-threshold? 
| | +--rw violate-action? 

| | -*--rw restart-timer? 

| -*--rw bgp-timers 

| | ---rw keepalive? uint1 
| | ---rw hold-time? uint1 
| +--rw authentication 

| | ---rw enable? 

| | ---rw keying-material 
LET *--rw (option)? 

Pai +--: (ao) 

E | -*--rw enable-ao 
LE | -*--rw ao-keycha 
lg *--:(md5) 

Pi | +--rw md5-keych 
R +--:(explicit) 

FT | +--rw key-id? 
| | +--rw key? 

| | | +--rw crypto-al 
p *--:(ipsec) 

T +--rw sa? 

| +--rw status 

| +--rw admin-status 

| | *--rw status? 

| | +--rw last-change? 

| *--ro oper-status 

| +--ro status? 

| +--ro last-change? 


Figure 16: BGP Routing Subtree Structure 
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The following data nodes are captured in Figure 16. It is up to the implementation (e.g., network 
orchestrator) to derive the corresponding BGP device configuration: 


'description: Includes a description of the BGP session. 


‘local-as': Indicates a local AS Number (ASN), if a distinct ASN is required other than the ASN 
configured at the VPN node level. 


'peer-as: Conveys the customer's ASN. 


‘address-family': Indicates the address family of the peer. It can be set to ‘ipv4’, 'ipv6’, or 'dual- 
stack’. 


This address family will be used together with the 'vpn-type' to derive the appropriate Address 
Family Identifiers (AFIs) / Subsequent Address Family Identifiers (SAFIs) that will be part of the 
derived device configurations (e.g., unicast IPv4 MPLS L3VPN (AFLSAFI = 1,128) as defined in 
Section 4.3.4 of [RFC4364]). 


‘local-address': Specifies an address or a reference to an interface to use when establishing the 
BGP transport session. 


neighbor: Can indicate two neighbors (each for a given address family) or one neighbor (if the 
'address-family' attribute is set to 'dual-stack"). A list of IP address(es) of the BGP neighbor(s) 
can then be conveyed in this data node. 


‘multihop': Indicates the number of allowed IP hops between a PE and its BGP peer. 


‘as-override': If set, this parameter indicates whether ASN override is enabled, i.e., replacing the 
ASN of the customer specified in the AS_PATH BGP attribute with the ASN identified in the 
‘local-as' attribute. 


‘allow-own-as': Used in some topologies (e.g., hub-and-spoke) to allow the provider's ASN to be 
included in the AS_PATH BGP attribute received from a CE. Loops are prevented by setting 
‘allow-own-as' to a maximum number of the provider's ASN occurrences. By default, this 
parameter is set to '0' (that is, reject any AS PATH attribute that includes the provider's ASN). 


'prepend-global-as: When distinct ASNs are configured at the VPN node and network access 
levels, this parameter controls whether the ASN provided at the VPN node level is prepended to 
the AS PATH attribute. 


‘'send-default-route': Controls whether default routes can be advertised to the peer. 


'site-of-origin: Meant to uniquely identify the set of routes learned from a site via a particular 
CE-PE connection. It is used to prevent routing loops (Section 7 of [RFC4364]). The Site of Origin 
attribute is encoded as a Route Origin Extended Community. 


'ipv6-site-of-origin: Carries an IPv6 Address Specific BGP Extended Community that is used to 
indicate the Site of Origin for VRF information [RFC5701]. It is used to prevent routing loops. 


'redistribute-connected': Controls whether the PE-CE link is advertised to other PEs. 
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‘bgp-max-prefix': Controls the behavior when a prefix maximum is reached. 


'max-prefix': Indicates the maximum number of BGP prefixes allowed in the BGP session. If 
the limit is reached, the action indicated in 'violate-action' will be followed. 


‘warning-threshold': A warning notification is triggered when this limit is reached. 


'violate-action: Indicates which action to execute when the maximum number of BGP 
prefixes is reached. Examples of such actions include sending a warning message, 
discarding extra paths from the peer, or restarting the session. 


'restart-timer': Indicates, in seconds, the time interval after which the BGP session will be 
reestablished. 
bgp-timers: Two timers can be captured in this container: (1) 'hold-time', which is the time 
interval that will be used for the Hold Timer (Section 4.2 of [RFC4271]) when establishing a BGP 
session and (2) 'keepalive', which is the time interval for the KeepaliveTimer between a PE and 
a BGP peer (Section 4.4 of [RFC4271]). Both timers are expressed in seconds. 


'authentication: The module adheres to the recommendations in Section 13.2 of [RFC4364], as it 
allows enabling the TCP Authentication Option (TCP-AO) [RFC5925] and accommodates the 
installed base that makes use of MD5. In addition, the module includes a provision for using 


IPsec. 


This version of the L3NM assumes that parameters specific to the TCP-AO are preconfigured as 
part of the key chain that is referenced in the L3NM. No assumption is made about how such a 
key chain is preconfigured. However, the structure of the key chain should cover data nodes 
beyond those in [RFC8177], mainly SendID and RecvID (Section 3.1 of [RFC5925]). 


'status: Indicates the status of the BGP routing instance. 


7.6.3.3. OSPF 
OSPF can be configured to run as a routing protocol on the 'vpn-network-access'. 


The OSPF routing subtree structure is shown in Figure 17. 
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*--rw routing-protocols 
*--rw routing-protocol* [id] 


*--rw ospf 

*--rw address-family? identityref 

*--rw area-id yang:dotted-quad 

+--rw metric? uint16 

+--rw sham-links  (vpn-common:rtg-ospf-sham-link)? 
| +--rw sham-link* [target-site] 


| t--rw target-site string 

| +--rw metric? uint16 
+--rw max-lsa? uint32 
+--rw authentication 

| +--rw enable? boolean 


+--rw keying-material 
+--rw (option)? 
*--:(auth-key-chain) 
| +--rw key-chain? 
| key-chain:key-chain-ref 
*--:(auth-key-explicit) 


| 
| 
| 
| 
| 
| 
| 
| 
| | +--rw crypto-algorithm? 
| 
| 
T 


| +--rw key-id? uint32 
| +--rw key? string 
| identityref 
*--:(ipsec) 
+--rw sa? string 
--rw status 
*--rw admin-status 
| +--rw status? identityref 


| -*--rw last-change? yang:date-and-time 
*--ro oper-status 

*--ro status? identityref 

*--ro last-change? yang:date-and-time 


Figure 17: OSPF Routing Subtree Structure 


The following data nodes are captured in Figure 17: 


‘address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. 


When the IPv4 or dual-stack address family is requested, it is up to the implementation (e.g., 
network orchestrator) to decide whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to 
announce IPv4 routes. Such a decision will typically be reflected in the device configurations 
that will be derived to implement the L3VPN. 


'area-id: Indicates the OSPF Area ID. 
'metric: Associates a metric with OSPF routes. 


'sham-links': Used to create OSPF sham links between two VPN network accesses sharing the 
same area and having a backdoor link (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). 
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'max-sa: Sets the maximum number of Link State Advertisements (LSAs) that the OSPF 
instance will accept. 


'authentication: Controls the authentication schemes to be enabled for the OSPF instance. The 
following options are supported: IPsec for OSPFv3 authentication [RFC4552], and the 
Authentication Trailer for OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. 


'status: Indicates the status of the OSPF routing instance. 


7.6.3.4. IS-IS 


The model allows the user to configure IS-IS [5010589] [RFC1195] [RFC5308] to run on the 'vpn- 
network-access' interface. See Figure 18. 


*--rw routing-protocols 
*--rw routing-protocol* [id] 
*--cpw isis 
*--rw address-family? identityref 


+--rw area-address area-address 
*--rw level? identityref 

+--rw metric? uint16 

+--rw mode? enumeration 

+--rw authentication 

| +--rw enable? boolean 


| -*--rw keying-material 

| +--rw (option)? 

| +--:(auth-key-chain) 

| | +--rw key-chain? 

| | key-chain:key-chain-ref 
| +--:(auth-key-explicit) 

| +--rw key-id? uint32 
| 

| 

T 


+--rw key? string 
+--rw crypto-algorithm? identityref 
--rw status 
*--rw admin-status 
| +--rw status? identityref 


| -*--rw last-change? yang:date-and-time 
*--ro oper-status 

*--ro status? identityref 

*--ro last-change? yang:date-and-time 


Figure 18: IS-IS Routing Subtree Structure 


The following IS-IS data nodes are supported: 


‘address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. 
'area-address': Indicates the IS-IS area address. 


level: Indicates the IS-IS level: Level 1, Level 2, or both. 
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'metric: Associates a metric with IS-IS routes. 


'mode' Indicates the IS-IS interface mode type. It can be set to 'active' (that is, send or receive IS- 
IS protocol control packets) or 'passive' (that is, suppress the sending of IS-IS updates through 
the interface). 


‘authentication’: Controls the authentication schemes to be enabled for the IS-IS instance. Both 
the specification of a key chain [RFC8177] and the direct specification of key and 
authentication algorithms are supported. 


'status: Indicates the status of the IS-IS routing instance. 


7.6.3.5. RIP 


The model allows the user to configure RIP to run on the 'vpn-network-access' interface. See 
Figure 19. 


*--rw routing-protocols 
*--rw routing-protocol* [id] 


uS (pall) 
*--rw address-family? identityref 
+--rw timers 


| -*--rw update-interval? uint16 
| -*--rw invalid-interval? uint16 
| -*--rw holddown-interval? uint16 
| +--rw flush-interval? uint16 


+--rw default-metric? uint8 

+--rw authentication 

| +--rw enable? boolean 

| +--rw keying-material 

| +--rw (option)? 

| +--:(auth-key-chain) 

| | +--rw key-chain? 

| | key-chain:key-chain-ref 
| +--:(auth-key-explicit) 
| 

| 

T 


+--rw key? string 
+--rw crypto-algorithm? identityref 
--rw status 
*--rw admin-status 
| +--rw status? identityref 


| -*--rw last-change? yang:date-and-time 
*--ro oper-status 

+--ro status? identityref 

*--ro last-change? yang:date-and-time 


Figure 19: RIP Subtree Structure 


As shown in Figure 19, the following RIP data nodes are supported: 


‘address-family': 
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Indicates whether IPv4, IPv6, or both address families are to be activated. This parameter is 
used to determine whether RIPv2 [RFC2453], RIP Next Generation (RIPng), or both are to be 
enabled [RFC2080]. 


‘timers': Indicates the following timers: 
‘update-interval': The interval at which RIP updates are sent. 
‘invalid-interval': The interval before a RIP route is declared invalid. 
‘holddown-interval': The interval before better RIP routes are released. 
‘flush-interval': The interval before a route is removed from the routing table. 
These timers are expressed in seconds. 
‘default-metric': Sets the default RIP metric. 
‘authentication’: Controls the authentication schemes to be enabled for the RIP instance. 
'status: Indicates the status of the RIP routing instance. 


7.6.3.6. VRRP 


The model allows enabling the Virtual Router Redundancy Protocol (VRRP) on the 'vpn-network- 
access' interface. See Figure 20. 


*--rw routing-protocols 
*--rw routing-protocol* [id] 
*--rw vrrp 
*--rw address-family* identityref 


+--rw vrrp-group? uint8 

+--rw backup-peer? inet:ip-address 
*--rw virtual-ip-address* inet:ip-address 
+--rw priority? uint8 


+--rw status 
+--rw admin-status 
| +--rw status? identityref 
| +--rw last-change? yang:date-and-time 
+--ro oper-status 
+--ro status? identityref 


| 
| 
| 
| 
| 
| 
| 
| 
| +--rw ping-reply? boolean 
| 
| 
| 
| 
| 
l +--ro last-change? yang:date-and-time 


Figure 20: VRRP Subtree Structure 


The following data nodes are supported: 


'address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. Note 
that VRRP version 3 [RFC5798] supports both IPv4 and IPv6. 
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'vrrp-group: Used to identify the VRRP group. 

‘backup-peer': Carries the IP address of the peer. 

'virtual-ip-address: Includes virtual IP addresses for a single VRRP group. 
'priority: Assigns the VRRP election priority for the backup virtual router. 
‘ping-reply': Controls whether the VRRP speaker should reply to ping requests. 


‘status': Indicates the status of the VRRP instance. 


Note that no authentication data node is included for VRRP, as there isn't any type of VRRP 
authentication at this time (see Section 9 of [RFC5798]). 


7.6.4. OAM 


This container (Figure 21) defines the Operations, Administration, and Maintenance (OAM) 
mechanisms used for a VPN network access. In the current version of the L3NM, only BFD is 
supported. 


+o rw oam 
+--rw bfd {vpn-common:bfd}? 


+--rw session-type? identityref 
+--rw desired-min-tx-interval? uint32 
+--rw required-min-rx-interval? uint32 
+--rw local-multiplier? uint8 

+--rw holdtime? uint32 
+--rw profile? leafref 
+--rw authentication! 


| +--rw meticulous? boolean 
+--rw status 
+--rw admin-status 
| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
*--ro oper-status 
+--ro status? identityref 


| 

| 

| 

| 

| 

| 

| 

| | +--rw key-chain? key-chain:key-chain-ref 
| 

| 

| 

| 

| 

| 

| +--ro last-change? yang:date-and-time 


Figure 21: IP Connection Subtree Structure (OAM) 
The following OAM data nodes can be specified: 
'session-type'": Indicates which BFD flavor is used to set up the session (e.g., classic BFD 


[RFC5880], Seamless BFD [RFC7880]). By default, it is assumed that the BFD session will follow 
the behavior specified in [RFC5880]. 


'desired-min-tx-interval: The minimum interval, in microseconds, that a PE would like to use 
when transmitting BFD Control packets, less any jitter applied. 
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‘required-min-rx-interval': The minimum interval, in microseconds, between received BFD 
Control packets that a PE is capable of supporting, less any jitter applied by the sender. 


‘local-multiplier': The negotiated transmit interval, multiplied by this value, provides the 
detection time for the peer. 


‘holdtime': Used to indicate the expected BFD holddown time, in milliseconds. This value may be 
inherited from the service request (see Section 6.3.2.2.2 of [RFC8299]). 


'profile: Refers to a BFD profile (Section 7.2). Such a profile can be set by the provider or 
inherited from the service request (see Section 6.3.2.2.2 of [RFC8299]). 


‘authentication’: Includes the required information to enable the BFD authentication modes 
discussed in Section 6.7 of [RFC5880]. In particular, 'meticulous' controls the activation of 
meticulous mode as discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. 


'status: Indicates the status of BFD. 


7.6.5. Security 


The 'security' container specifies the authentication and the encryption to be applied to traffic for 
a given VPN network access. As depicted in the subtree shown in Figure 22, the L3NM can be used 
to directly control the encryption to be applied (e.g., Layer 2 or Layer 3 encryption) or invoke a 
local encryption profile. 


+--rw vpn-services 
*--rw vpn-service* [vpn-id] 


t--rW vpn-nodes 
*--rw vpn-node* [vpn-node-id] 


*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


+--rw security 
| -*--rw encryption {vpn-common:encryption}? 

| | ---rw enabled? boolean 

| | ---rw layer? enumeration 

| -*--rw encryption-profile 

| +--rw (profile)? 

| +--:(provider-profile) 

| | +--rw profile-name? leafref 
| +--:(customer-profile) 

| +--rw customer-key-chain? 

| key-chain:key-chain-ref 
+--rw service 


Figure 22: Security Subtree Structure 
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7.6.6. Services 


7.6.6.1. Overview 


The 'service' container specifies the service parameters to apply for a given VPN network access 
(Figure 23). 


*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


+--rw service 
+--rw pe-to-ce-bandwidth? uint64 (vpn-common:inbound-bw)? 
*--rw ce-to-pe-bandwidth? uint64 {vpn-common:outbound-bw}? 
+--rw mtu? uint32 
+--rw qos {vpn-common:qos}? 
lf. agers 
+--rw carriers-carrier 
| (vpn-common:carriers-carrier)? 
| -*--rw signaling-type? enumeration 


+--rw ntp 

| +--rw broadcast? enumeration 
*--rw auth-profile 
| -*--rw profile-id? string 


+--rw status 
+--rw admin-status 


| 
| 
| 
| 
| 
| 
| +--ro oper-status 
| 
| 
T 


| +--rw status? identityref 
| -*--rw last-change? yang:date-and-time 
+--ro status? identityref 
+--ro last-change? yang:date-and-time 
--rw multicast {vpn-common:multicast}? 


Figure 23: Services Subtree Structure 


The following data nodes are defined: 


‘pe-to-ce-bandwidth': Indicates, in bits per second (bps), the inbound bandwidth of the 
connection (i.e., the download bandwidth from the service provider to the site). 


‘ce-to-pe-bandwidth': Indicates, in bps, the outbound bandwidth of the connection (i.e., the 
upload bandwidth from the site to the service provider). 


' T 


mtu': Indicates the MTU at the service level. 


‘qos': Used to define a set of QoS policies to apply on a given connection (refer to Section 7.6.6.2 
for more details). 


'carriers-carrier: Groups a set of parameters that are used when Carriers' Carriers (CsC) is 
enabled, such as using BGP for signaling purposes [RFC8277]. 
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ntp: Time synchronization may be needed in some VPNs, such as infrastructure and 
management VPNs. This container is used to enable the NTP service [RFC5905]. 


"multicast: Specifies the multicast mode and other data nodes, such as the address family. Refer 


to Section 7.7. 


7.6.6.2. QoS 


The 'qos' container is used to define a set of QoS policies to apply on a given connection (Figure 
24). A QoS policy may be a classification or an action policy. For example, a QoS action can be 
defined to rate-limit inbound/outbound traffic of a given class of service. 


t--rW qos {vpn- 


+--rw 


+--rw 
+--rw 


common :qos}? 


id 


profile 
direction? 


+--rw qos-classification-policy 
| +--rw rule* [id] 


string 


+--rw outbound-rate-limit? decimal64 
+--rw qos-profile 
+--rw qos-profile* [profile] 
leafref 
identityref 


| 

| 

"ul 

ea *--rw (match-type)? 

ER | +--:(match-flow) 

EY | | +--rw (13)? 

| | | | | LAN 

| | | | | *--:(ipv6) 

| | | | +--rw (14)? 

| | | | ms 

| | | | *--:(udp) 

inane | +--:(match-application) 

ee | +--rw match-application? 

[E | identityref 

ler *--rw target-class-id? string 

| *--rw qos-action 

| | -*--rw rule* [id] 

el +--rw id string 
lf +--rw target-class-id? string 
II +--rw inbound-rate-limit? decimal64 
Jaa 

| 

| 

| 


Figure 24: Overall QoS Subtree Structure 


QoS classification can be based on many criteria, such as the following: 


Layer3: As shown in Figure 25, classification can be based on any IP header field ora 
combination thereof. Both IPv4 and IPv6 are supported. 
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*--rw qos {vpn-common:qos}? 


*--rw qos-classification-policy 


+--rw rule* [id] 


+--rw id 


string 


*--rw (match-type)? 
*--:(match-flow) 


+--rw (13)? 

*--:(ipv4) 

| +--rw ipv4 

+--rw dscp? 
+--rw ecn? 
+--rw length? 
+--rw ttl? 
+--rw protocol? 
+--rw ihl? 
+--rw flags? 
+--rw offset? 
+--rw identification? 


inet :ipv4-prefix 

:(ipv6) 

+--rw ipv6 
+--rw dscp? 
+--rw ecn? 
+--rw length? 
+--rw ttl? 
+--rw protocol? 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| | 
| 

| 

| 

| 

| 

| 
+-- 


+--rw flow-label? 


Figure 25: QoS Subtree Structure (L3) 


inet :dscp 
uint8 
uinti16 
uint8 
uint8 
uint8 
bits 
uint16 
uint16 


*--rw (destination-network) ? 
*--:(destination-ipv4-network) 
| +--rw destination-ipv4-network? 
| inet:ipv4-prefix 
*--rw (source-network)? 
*--:(source-ipv4-network) 

*--rw source-ipv4-network? 


inet:dscp 
uint8 
uint16 
uint8 
uint8 


*--rw (destination-network)? 

| +--:(destination-ipv6-network) 

| +--rw destination-ipv6-network? 
| inet :ipv6-prefix 

*--rw (source-network) ? 

| +--:(source-ipv6-network) 

| *--rw source-ipv6-network? 

| inet :ipv6-prefix 


inet :ipv6-flow-label 


February 2022 


Layer 4: As discussed in [RFC9181], any Layer 4 protocol can be indicated in the 'protocol' data 
node under '13' (Figure 25), but only TCP- and UDP-specific match criteria are elaborated in this 
version, as these protocols are widely used in the context of VPN services. Augmentations can 


be considered in the future to add other Layer-4-specific data nodes, if needed. 


TCP- or UDP-related match criteria can be specified in the L3NM, as shown in Figure 26. 
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As discussed in [RFC9181], some transport protocols use existing protocols (e.g., TCP or UDP) as 
the substrate. The match criteria for such protocols may rely upon the 'protocol' setting under 
3, TCP/UDP match criteria as shown in Figure 26, part of the TCP/UDP payload, or a 
combination thereof. This version of the module does not support such advanced match 
criteria. Future revisions of the VPN common module or augmentations to the L3NM may 
consider adding match criteria based on the transport protocol payload (e.g., by means ofa 
bitmask match). 
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*--rw qos {vpn-common:qos}? 

*--rw qos-classification-policy 
| *--rw rule* [id] 

*--rw id string 
*--rw (match-type)? 

| *--:(match-flow) 


| *--rw (13)? 
*--rw (14)? 
T--:(tcp) 
| +--rw tcp 
+--rw sequence-number? uint32 
*--rw acknowledgement-number? uint32 
*--rw data-offset? uint8 
+--rw reserved? uint8 
*--rw flags? bits 
*--rw window-size? uint16 
+--rw urgent-pointer? uint16 
+--rw options? binary 


| 
| 
| 
| 
| 
| 
| 
| *--rw (source-port)? 
| | +--:(source-port-range-or-operator) 
| | +--rw source-port-range-or-operator 
| | *--rw (port-range-or-operator)? 
l | +--:(range) 
l | | +--rw lower-port 
| | RN inet:port-number 
| l | +--rw upper-port 
| | | inet:port-number 
l | +--:(operator) 
l | +--rw operator? operator 
| | ESTN POE 
| | inet:port-number 
| +--rw (destination-port)? 
l +--:(destination-port-range-or-operator) 
| +--rw destination-port-range-or-operator 
| *--rw (port-range-or-operator)? 
| +--:(range) 
| | +--rw lower-port 
| st inet:port-number 
| | +--rw upper-port 
| | inet:port-number 
| *--:(operator) 
l +--rw operator? operator 
| +t-=rw port 
| inet:port-number 
*--:(udp) 
+--rw udp 
+--rw length? uint16 
+--rw (source-port)? 
| +--:(source-port-range-or-operator) 
| *--rw source-port-range-or-operator 
| *--rw (port-range-or-operator)? 
| +--:(range) 
| | +--rw lower-port 
| | | inet:port-number 
| | +--rw upper-port 
| | inet:port-number 
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l +--:(operator) 
| +--rw operator? operator 
| +--rw port 
| inet:port-number 
*--rw (destination-port)? 
*--:(destination-port-range-or-operator) 
+--rw destination-port-range-or-operator 
*--rw (port-range-or-operator)? 
*--:(range) 
| -*--rw lower-port 
| | inet:port-number 
| -*--rw upper-port 
| inet:port-number 
*--:(operator) 
*--rw operator? operator 
+- rw port 
inet:port-number 


Figure 26: QoS Subtree Structure (L4) 


Application match: Relies upon application-specific classification (Figure 24). 


7.7. Multicast 


Multicast may be enabled for a particular VPN at the VPN node and VPN network access levels 
(see Figure 27). Some data nodes (e.g., max-groups (Figure 28)) can be controlled at various levels: 
VPN service, VPN node level, or VPN network access. 
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+--rw vpn-services 
*--rw vpn-service* [vpn-id] 


*--rw vpn-instance-profiles 
| +--rw vpn-instance-profile* [profile-id] 


*--rw multicast {vpn-common:multicast}? 
| 


+--rw vpn-nodes 
+--rw vpn-node* [vpn-node-id] 


+--rw active-vpn-instance-profiles 
| +--rw vpn-instance-profile* [profile-id] 


+--rw multicast {vpn-common:multicast}? 
| 


*--rw vpn-network-accesses 
*--rw vpn-network-access* [id] 


+--rw service 


*--rw multicast {vpn-common:multicast}? 


Figure 27: Overall Multicast Subtree Structure 


Multicast-related data nodes at the VPN instance profile level have the structure shown in Figure 
28. 
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+--rw vpn-services 
*--rw vpn-service* [vpn-id] 


*--rw vpn-instance-profiles 
*--rw vpn-instance-profile* [profile-id] 


*--rw multicast {vpn-common:multicast}? 
+--rw tree-flavor? . identityref 
*--rw rp 
| +--rw rp-group-mappings 

| -*--rw rp-group-mapping* [id] 


+--rw id uint16 

+--rw provider-managed 

| +--rw enabled? boolean 
+--rw rp-redundancy? boolean 


| 

| -*--rw optimal-traffic-delivery? boolean 
| -*--rw anycast 
| 


*--rw local-address? inet:ip-address 
| +--rw rp-set-address* inet:ip-address 
+--rw rp-address inet:ip-address 


+--rw groups 
+--rw group* [id] 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| *--rw (group-format) 
| 
| 
| 
| 
| 
| 
| 
| 
T 


+--rw id uint16 
+--:(group-prefix) 
| +--rw group-address? 
| inet:ip-prefix 
*--:(startend) 
+--rw group-start? 
| inet:ip-address 
*--rw group-end? 
| inet:ip-address 
--rw rp-discovery 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| +--rw rp-discovery-type? identityref 

| +--rw bsr-candidates 

| +--rw bsr-candidate-address* 

| | inet:ip-address 

*--rw igmp {vpn-common:igmp and vpn-common:ipv4)? 
| +--rw static-group* [group-addr] 

| | ---rw group-addr 

e d rt-types:ipv4-multicast-group-address 
| | ---rw source-addr? 

LE rt-types:ipv4-multicast-source-address 
| *--rw max-groups? uint32 

| *--rw max-entries? uint32 

| +--rw version? identityref 

+--rw mld {vpn-common:mld and vpn-common:ipv6}? 

| +--rw static-group* [group-addr ] 

| | ---rw group-addr 

ho rt-types:ipv6-multicast-group-address 
| | ---rw source-addr? 

"sl rt-types:ipv6-multicast-source-address 
| *--rw max-groups? uint32 

| *--rw max-entries? uint32 

| +--rw version? identityref 

*--rw pim {vpn-common:pim}? 
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l +--rw hello-interval? 
| | rt-types:timer-value-seconds16 
| *--rw dr-priority? uint32 


Figure 28: Multicast Subtree Structure (VPN Instance Profile Level) 


The model supports a single type of tree per VPN access (‘tree-flavor'): Any-Source Multicast 
(ASM), Source-Specific Multicast (SSM), or bidirectional. 


When ASM is used, the model supports the configuration of Rendezvous Points (RPs). RP 
discovery may be 'static', 'bsr-rp', or 'auto-rp'. When set to 'static', RP-to-multicast-group mappings 
MUST be configured as part of the 'rp-group-mappings' container. The RP MAY be a provider node 
or a customer node. When the RP is a customer node, the RP address must be configured using the 
'rp-address' leaf. 


The model supports RP redundancy through the 'rp-redundancy' leaf. How the redundancy is 
achieved is out of scope. 


When a particular VPN using ASM requires traffic delivery that is more optimal (e.g. requested 
per the guidance in [RFC8299]), 'optimal-traffic-delivery' can be set. When set to 'true', the 
implementation must use any mechanism to provide traffic delivery that is more optimal for the 
customer. For example, anycast is one of the mechanisms for enhancing RP redundancy, 
providing resilience against failures, and recovering from failures quickly. 


When configuring multicast-related parameters at the VPN node level (Figure 29), the same 
structure as the structure depicted in Figure 30 is used. When defined at the VPN node level, 
Internet Group Management Protocol (IGMP) parameters [RFC1112] [RFC2236] [RFC3376], 
Multicast Listener Discovery (MLD) parameters [RFC2710] [RFC3810], and Protocol Independent 
Multicast (PIM) parameters [RFC7761] are applicable to all VPN network accesses of that VPN 
node unless corresponding nodes are overridden at the VPN network access level. 
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vpn-nodes 


*--rw vpn-node* [vpn-node-id] 


Figure 29: 


*--rw active-vpn-instance-profiles 
*--rw vpn-instance-profile* [profile-id] 


| 

| t 

| +--rw multicast {vpn-common:multicast}? 

| +--rw tree-flavor*  identityref 

l +--rw rp 

| || eee 

| *--rw igmp {vpn-common:igmp and vpn-common:ipv4)? 
| S 

| +--rw mld {vpn-common:mld and vpn-common:ipv6}? 
| 

| 


*--rw pim {vpn-common:pim}? 


Multicast Subtree Structure (VPN Node Level) 


February 2022 


Multicast-related data nodes at the VPN network access level are shown in Figure 30. The values 
configured at the VPN network access level override the values configured for the corresponding 
data nodes at other levels. 
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*--rw vpn-network-accesses 


*--rw vpn-network-access* [id] 


+--rw service 
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*--rw multicast {vpn-common:multicast}? 


*--rw access-type? enumeration 
*--rw address-family? identityref 
*--rw protocol-type? enumeration 
+--rw remote-source? boolean 


+--rw igmp 


{vpn-common:igmp}? 


| +--rw static-group* [group-addr ] 


| -*--rw group-addr 


| rt-types:ipv4-multicast-group-address 


| -*--rw source-addr? 


| rt-types:ipv4-multicast-source-address 


+--rw max-groups? 
+--rw max-entries? 
*--rw max-group-sources? 
+--rw version? 
+--rw status 
+--rw admin-status 
| +--rw status? 
| -*--rw last-change? 
+--ro oper-status 
+--ro status? 
+--ro last-change? 
--rw mld {vpn-common:mld}? 


| -*--rw group-addr 


uint32 
uint32 
Unit 32 
identityref 


identityref 
yang:date-and-time 


identityref 
yang:date-and-time 


| rt-types:ipv6-multicast-group-address 


| -*--rw source-addr? 


| rt-types:ipv6-multicast-source-address 


+--rw max-groups? 
+--rw max-entries? 
*--rw max-group-sources? 
+--rw version? 
+--rw status 
+--rw admin-status 
| +--rw status? 
| -*--rw last-change? 
+--ro oper-status 
+--ro status? 
*--ro last-change? 
--rw pim (vpn-common:pim)? 
+--rw hello-interval? 
*--rw dr-priority? 
+--rw status 
+--rw admin-status 
| +--rw status? 
| +--rw last-change? 
+--ro oper-status 
+--ro status? 
+--ro last-change? 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 
| *--rw static-group* [group-addr] 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
+ 
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uint32 
uint32 
uint32 
identityref 


identityref 
yang: date-and-time 


identityref 
yang: date-and-time 


rt-types:timer-value-seconds16 
uint32 


identityref 
yang:date-and-time 


identityref 
yang:date-and-time 
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Figure 30: Multicast Subtree Structure (VPN Network Access Level) 


8. L3NM YANG Module 


This module uses types defined in [RFC6991], [RFC8343], and [RFC9181]. It also uses groupings 
defined in [RFC8519], [RFC8177], and [RFC8294]. 
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«CODE BEGINS» file "ietf-13vpn-ntw02022-02-14.yang" 


module ietf-l3vpn-ntw { 
yang-version 1.1; 
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw'; 
prefix 13nm; 


import ietf-vpn-common { 
prefix vpn-common; 
reference 
"RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 
VPNs"; 
} 
import ietf-inet-types { 
prefix inet; 
reference 
"RFC 6991: Common YANG Data Types, Section 4"; 
} 


import ietf-yang-types { 
prefix yang; 
reference 
"RFC 6991: Common YANG Data Types, Section 3"; 
} 


import ietf-key-chain { 
prefix key-chain; 
reference 
"RFC 8177: YANG Data Model for Key Chains"; 
} 


import ietf-routing-types { 
prefix rt-types; 
reference 
"RFC 8294: Common YANG Data Types for the Routing Area"; 


} 
import ietf-interfaces { 
prefix if; 
reference 
"RFC 8343: A YANG Data Model for Interface Management"; 
} 
organization 
"IETF OPSAWG (Operations and Management Area Working Group)"; 
contact 
"WG Web: «https://datatracker.ietf.org/wg/opsawg/» 
WG List: <mailto:opsawg@ietf.org> 
Author: Samier Barguil 
<mailto:samier.barguilgiraldo.ext@telefonica.com> 
Editor: Oscar Gonzalez de Dios 
<mailto:oscar.gonzalezdedios@telefonica.com> 
Editor: Mohamed Boucadair 
<mailto:mohamed.boucadair@orange.com> 
Author: Luis Angel Munoz 
<mailto:luis-angel.munoz@vodafone.com> 
Author: Alejandro Aguado 
<mailto:alejandro.aguado_martin@nokia.com>"; 
description 


"This YANG module defines a generic network-oriented model 
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for the configuration of Layer 3 Virtual Private Networks. 


Copyright (c) 2022 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Revised BSD License 
set forth in Section 4.c of the IETF Trust's Legal Provisions 
Relating to IETF Documents 
(https://trustee.ietf.org/license-info). 


This version of this YANG module is part of RFC 9182; see the 
RFC itself for full legal notices."; 


revision 2022-02-14 { 
description 
"Initial revision."; 
reference 
"RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; 
} 


/* Features */ 


feature msdp { 
description 
"This feature indicates that Multicast Source Discovery 
Protocol (MSDP) capabilities are supported by the VPN."; 
reference 
"RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 


} 
/* Identities */ 


identity address-allocation-type { 
description 
"Base identity for address allocation type in the 
Provider Edge to Customer Edge (PE-CE) link."; 
} 


identity provider-dhcp { 
base address-allocation-type; 
description 
"The provider's network provides a DHCP service to the 
customer."; 


} 


identity provider-dhcp-relay { 
base address-allocation-type; 
description 
"The provider's network provides a DHCP relay service to the 
customer."; 


} 


identity provider-dhcp-slaac { 
if-feature "vpn-common:ipv6"; 
base address-allocation-type; 
description 
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"The provider's network provides a DHCP service to the 
customer as well as IPv6 Stateless Address 
Autoconfiguration (SLAAC)."; 

reference 
"RFC 4862: IPv6 Stateless Address Autoconfiguration" ; 


} 


identity static-address { 
base address-allocation-type; 
description 
"The provider's network provides static IP addressing to the 
customer."; 


} 


identity slaac { 

if-feature "vpn-common:ipv6"; 

base address-allocation-type; 

description 
"The provider's network uses IPv6 SLAAC to provide 
addressing to the customer."; 

reference 
"RFC 4862: IPv6 Stateless Address Autoconfiguration"; 


} 
identity local-defined-next-hop { 
description 
"Base identity of local defined next hops."; 
} 


identity discard { 
base local-defined-next-hop; 
description 
"Indicates an action to discard traffic for the 
corresponding destination. 
For example, this can be used to black-hole traffic."; 


} 


identity local-link { 
base local-defined-next-hop; 
description 
"Treat traffic towards addresses within the specified 
next-hop prefix as though they are connected to a local 


Link: 
} 
identity 12-tunnel-type { 
description 
"Base identity for Layer 2 tunnel selection under the VPN 
network access."; 
} 


identity pseudowire { 
base 12-tunnel-type; 
description 
"Pseudowire tunnel termination in the VPN network access."; 


} 


identity vpls { 
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base 12-tunnel-type; 

description 
"Virtual Private LAN Service (VPLS) tunnel termination in 
the VPN network access."; 


} 


identity vxlan { 
base 12-tunnel-type; 
description 
"Virtual eXtensible Local Area Network (VXLAN) tunnel 
termination in the VPN network access."; 


} 
/* Typedefs */ 


typedef predefined-next-hop { 
type identityref { 
base local-defined-next-hop; 


description 
"Predefined next-hop designation for locally generated 
routes."; 


} 


typedef area-address { 
type string { 
pattern '[@-9A-Fa-f]{2}(\.[@-9A-Fa-f]{4}){0,6}'; 
} 


description 
"This type defines the area address format."; 
} 


/* Groupings */ 


grouping vpn-instance-profile { 
description 
"Grouping for data nodes that may be factorized 
among many levels of the model. The grouping can 
be used to define generic profiles at the VPN service 
level and then referenced at the VPN node and VPN 
network access levels."; 
leaf local-as { 
if-feature "vpn-common:rtg-bgp"; 
type inet:as-number; 
description 
"Provider's Autonomous System (AS) number. Used if the 
customer requests BGP routing."; 


uses vpn-common:route-distinguisher; 
list address-family { 
key "address-family"; 
description 
"Set of parameters per address family."; 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 


description 
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"Indicates the address family (IPv4 and/or IPv6)."; 
} 
container vpn-targets { 
description 
"Set of route targets to match for import and export 
routes to/from VRF."; 
uses vpn-common:vpn-route-targets; 


list maximum-routes { 

key "protocol"; 
description 

"Defines the maximum number of routes for VRF."; 
leaf protocol { 

type identityref { 

base vpn-common:routing-protocol-type; 
} 


description 
"Indicates the routing protocol. A value of ‘any' 
can be used to identify a limit that will apply for 
each active routing protocol."; 


leaf maximum-routes { 
type uint32; 
description 
"Indicates the maximum number of prefixes that VRF can 
accept for this address family and protocol."; 
} 
} 
} 
container multicast { 
if-feature "vpn-common:multicast"; 
description 
"Global multicast parameters."; 
leaf tree-flavor ( 
type identityref { 
base vpn-common:multicast-tree-type; 
} 
description 
"Type of the multicast tree to be used."; 


container rp { 
description 
"Rendezvous Point (RP) parameters." 
container rp-group-mappings { 
description 
"RP-to-group mapping parameters." 
list rp-group-mapping 
key "id"; 
description 
"List of RP-to-group mappings. 
leaf id ( 
type uint16; 
description 
"Unique identifier for the mapping."; 


} 
container provider-managed { 
description 
"Parameters for a provider-managed RP." 
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leaf enabled ( 
type boolean; 
default "false"; 
description 
"Set to 'true' if the RP must be a 
provider-managed node. Set to 'false' if it is 
a customer-managed node."; 


} 
leaf rp-redundancy { 
type boolean; 
default "false"; 
description 
"If set to ‘true’, it indicates that a 
redundancy mechanism for the RP is required."; 
} 
leaf optimal-traffic-delivery { 
type boolean; 
default "false"; 
description 
"If set to 'true', the service provider (SP) 
must ensure that the traffic uses an optimal 
path. An SP may use Anycast RP or 
RP-tree-to-SPT ('SPT' is 'shortest path tree') 
switchover architectures." ; 
} 
container anycast { 
when "../rp-redundancy = 'true' and 
../optimal-traffic-delivery = 'true'" { 
description 
"Only applicable if both RP redundancy and 
delivery through an optimal path are 
activated."; 
} 
description 
"PIM Anycast-RP parameters."; 
leaf local-address { 
type inet:ip-address; 
description 
"IP local address for the PIM RP. Usually 
corresponds to the Router ID or the 
primary address."; 


leaf-list rp-set-address { 
type inet:ip-address; 
description 
"Specifies the IP address of other RP routers 
that share the same RP IP address."; 
} 
} 


I 
leaf rp-address { 
when "../provider-managed/enabled = 'false'" { 
description 
"Relevant when the RP is not managed by the 
provider."; 


type inet:ip-address; 
mandatory true; 
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description 
"Defines the address of the RP. 
Used if the RP is managed by the customer."; 
} 
container groups { 
description 
"Multicast groups associated with the RP."; 
list group { 
key "id"; 
description 
"List of multicast groups."; 
leaf id ( 
type uint16; 
description 
"Identifier for the group."; 
} 


choice group-format { 
mandatory true; 
description 
"Choice for multicast group format."; 
case group-prefix { 
leaf group-address { 
type inet:ip-prefix; 
description 
"A single multicast group prefix."; 
} 
} 
case startend { 
leaf group-start { 
type inet:ip-address; 
description 
"The first multicast group address in 
the multicast group address range."; 


leaf group-end { 
type inet:ip-address; 
description 
"The last multicast group address in 
the multicast group address range."; 


container rp-discovery { 
description 
"RP discovery parameters."; 
leaf rp-discovery-type { 
type identityref { 
base vpn-common:multicast-rp-discovery-type; 


default "vpn-common:static-rp'; 
description 
"Type of RP discovery used."; 
} 


container bsr-candidates { 
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when "derived-from-or-self(../rp-discovery-type, 
+ "'vpn-common:bsr-rp')" { 
description 
"Only applicable if the discovery type 
is DST-nDE sues 
} 
description 
"Container for the customer Bootstrap Router (BSR) 
candidate's addresses."; 
leaf-list bsr-candidate-address { 
type inet:ip-address; 
description 
"Specifies the address of the candidate BSR."; 
} 
/ 
} 
} 
container igmp { 
if-feature "vpn-common:igmp and vpn-common:ipv4"; 
description 
"Includes IGMP-related parameters."; 
list static-group { 
key "group-addr"; 
description 
"Multicast static source/group associated with the 
IGMP session."; 
leaf group-addr { 
type rt-types:ipv4-multicast-group-address; 
description 
"Multicast group IPv4 address."; 


leaf source-addr { 
type rt-types:ipv4-multicast-source-address; 
description 
"Multicast source IPv4 address."; 
} 


} 
leaf max-groups { 
type uint32; 
description 
"Indicates the maximum number of groups."; 
} 


leaf max-entries { 
type uint32; 
description 
"Indicates the maximum number of IGMP entries."; 


leaf version ( 
type identityref { 
base vpn-common:igmp-version; 


default "vpn-common:igmpv2"; 
description 
"Indicates the IGMP version."; 
reference 
"RFC 1112: Host Extensions for IP Multicasting 
RFC 2236: Internet Group Management Protocol, 
Version 2 
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RFC 3376: Internet Group Management Protocol, 
Version 3"; 
} 
} 
container mld { 
if-feature "vpn-common:mld and vpn-common:ipv6"; 
description 
"Includes MLD-related parameters." ; 
list static-group { 
key "group-addr"; 
description 
"Multicast static source/group associated with the 
MLD session."; 
leaf group-addr { 
type rt-types:ipv6-multicast-group-address; 
description 
"Multicast group IPv6 address." ; 
} 


leaf source-addr { 
type rt-types:ipv6-multicast-source-address; 
description 
"Multicast source IPv6 address."; 
} 
} 


leaf max-groups { 
type uint32; 
description 
"Indicates the maximum number of groups."; 
} 
leaf max-entries { 
type uint32; 
description 
"Indicates the maximum number of MLD entries."; 


leaf version { 
type identityref { 
base vpn-common:mld-version; 


default "vpn-common:mldv2"; 
description 

"Indicates the MLD protocol version."; 
reference 


"RFC 2710: Multicast Listener Discovery (MLD) for IPv6 


RFC 3810: Multicast Listener Discovery Version 2 
(MLDv2) for IPv6"; 
} 
} 
container pim { 
if-feature "vpn-common:pim"; 
description 
"Only applies when the protocol type is 'pim'."; 
leaf hello-interval ( 
type rt-types:timer-value-seconds16; 
default "30": 
description 
"Interval between PIM Hello messages. If set to 
'infinity' or 'not-set', no periodic Hello messages 
are sent."; 
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reference 
"RFC 7761: Protocol Independent Multicast - Sparse 
Mode (PIM-SM): Protocol Specification 
(Revised), Section 4.11 
RFC 8294: Common YANG Data Types for the Routing 
Area"; 


} 
leaf dr-priority { 
type uint32; 
default "1"; 
description 
"Indicates the preference associated with the 
Designated Router (DR) election process. A larger 
value has a higher priority over a smaller value."; 
reference 
"RFC 7761: Protocol Independent Multicast - Sparse 
Mode (PIM-SM): Protocol Specification 
(Revised), Section 4.3.2"; 
} 
} 
} 
} 


/* Main Blocks */ 
/* Main 13vpn-ntw */ 


container l3vpn-ntw { 
description 
"Main container for management of Layer 3 Virtual Private 
Network (L3VPN) services."; 
container vpn-profiles { 
description 
"Contains a set of valid VPN profiles to reference 
in the VPN service."; 
uses vpn-common:vpn-profile-cfg; 


container vpn-services { 
description 
"Container for the VPN services."; 
list vpn-service { 
key "vpn-id"; 
description 
"List of VPN services."; 
uses vpn-common:vpn-description; 
leaf parent-service-id { 
type vpn-common:vpn-id; 
description 
"Pointer to the parent service, if any. 
A parent service can be an L3SM, a slice request, 
a VPN+ service, etc."; 
} 
leaf vpn-type { 
type identityref { 
base vpn-common:service-type; 


description 
"Indicates the service type."; 
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leaf vpn-service-topology { 
type identityref { 
base vpn-common:vpn-topology; 


default "vpn-common:any-to-any"; 
description 
"VPN service topology."; 
} 
uses vpn-common:service-status; 
container vpn-instance-profiles { 
description 
"Container for a list of VPN instance profiles."; 
list vpn-instance-profile { 
key "profile-id"; 
description 
"List of VPN instance profiles."; 
leaf profile-id { 
type string; 
description 
"VPN instance profile identifier."; 


} 
leaf role { 
type identityref { 
base vpn-common:role; 


default "vpn-common:any-to-any-role"; 
description 
"Role of the VPN node in the VPN."; 
} 
uses vpn-instance-profile; 
} 
} 


container underlay-transport { 
description 
"Container for the underlay transport."; 
uses vpn-common:underlay-transport; 
} 
container external-connectivity { 
if-feature "vpn-common:external-connectivity"; 
description 
"Container for external connectivity."; 
choice profile { 
description 
"Choice for the external connectivity profile."; 
case profile { 
leaf profile-name { 
type leafref { 
path "/13vpn-ntw/vpn-profiles" 
+ "/valid-provider-identifiers" 
+ "/external-connectivity-identifier/id'; 
} 
description 
"Name of the service provider's profile to be 
applied at the VPN service level."; 
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container vpn-nodes { 
description 
"Container for VPN nodes."; 
list vpn-node { 
key "vpn-node-id'; 
description 
"Includes a list of VPN nodes."; 
leaf vpn-node-id { 
type vpn-common:vpn-id; 
description 
"An identifier of the VPN node."; 


leaf description { 
type string; 
description 
"Textual description of the VPN node."; 


} 
leaf ne-id { 
type string; 
description 
"Unique identifier of the network element where 
the VPN node is deployed."; 


leaf local-as { 
if-feature "vpn-common:rtg-bgp"; 
type inet:as-number; 
description 
"Provider's AS number. Used if the customer 
requests BGP routing."; 


leaf router-id { 
type rt-types:router-id; 
description 
"A 32-bit number in the dotted-quad format that is 
used to uniquely identify a node within an AS. 
This identifier is used for both IPv4 and IPv6."; 
} 
container active-vpn-instance-profiles { 
description 
"Container for active VPN instance profiles."; 
list vpn-instance-profile { 
key "profile-id"; 
description 
"Includes a list of active VPN instance 
profiles."; 
leaf profile-id { 
type leafref { 
path "/13vpn-ntw/vpn-services/vpn-service" 
+ "/vpn-instance-profiles" 
+ "/vpn-instance-profile/profile-id"; 
/ 
description 
"Node's active VPN instance profile."; 
} 


list router-id { 
key "address-family"; 
description 
"Router ID per address family."; 
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leaf address-family { 
type identityref { 
base vpn-common:address-family; 
} 
description 
"Indicates the address family for which the 
Router ID applies."; 


leaf router-id { 
type inet:ip-address; 
description 
"The 'router-id' information can be an IPv4 
or IPv6 address. This can be used, 
for example, to configure an IPv6 address 
as a Router ID when such a capability is 
supported by underlay routers. In such a 
case, the configured value overrides the 
generic value defined at the VPN node 
level."; 
} 
} 
uses vpn-instance-profile; 


} 
container msdp { 
if-feature "msdp"; 
description 
"Includes MSDP-related parameters."; 
leaf peer { 
type inet:ipv4-address; 
description 
"Indicates the IPv4 address of the MSDP peer."; 


leaf local-address { 
type inet:ipv4-address; 
description 
"Indicates the IPv4 address of the local end. 
This local address must be configured on 
the node."; 
} . 
uses vpn-common:service-status; 
} 
uses vpn-common:vpn-components-group; 
uses vpn-common:service-status; 
container vpn-network-accesses { 
description 
"List of network accesses."; 
list vpn-network-access { 
key "id"; 
description 
"List of network accesses."; 
leaf id ( 
type vpn-common:vpn-id; 
description 
"Identifier for the network access."; 


leaf interface-id { 
type string; 
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description 
"Identifier for the physical or logical 
interface. 
The identification of the sub-interface 
is provided at the connection level and/or 
the IP connection level."; 


leaf description { 
type string; 
description 
"Textual description of the network access."; 
} 
leaf vpn-network-access-type { 
type identityref { 
base vpn-common:site-network-access-type; 


default "vpn-common:point-to-point"; 
description 
"Describes the type of connection, e.g., 
point to point."; 


leaf vpn-instance-profile { 
type leafref ( 
path "/13vpn-ntw/vpn-services/vpn-service" 
* "/vpn-nodes/vpn-node" 
* "/active-vpn-instance-profiles" 
+ "/vpn-instance-profile/profile-id"'; 


} 

description 
"An identifier of an active VPN instance 
profiles; 


uses vpn-common:service-status; 
container connection { 
description 
"Defines Layer 2 protocols and parameters that 
are required to enable connectivity between 
the PE and the CE."; 
container encapsulation { 
description 
"Container for Layer 2 encapsulation."; 
leaf type { 
type identityref { 
base vpn-common:encapsulation-type; 


default "vpn-common:priority-tagged'; 
description 
"Encapsulation type. By default, the type 
of the tagged interface is 
'priority-tagged'."; 
} 
container dotiq { 
when "derived-from-or-self(../type, 
+ "'vpn-common:dotiq')" { 
description 
"Only applies when the type of the 
tagged interface is 'dotiq'."; 
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description 
"Tagged interface."; 
leaf tag-type { 
type identityref { 
base vpn-common:tag-type; 


default "vpn-common:c-vlan"; 
description 
"Tag type. By default, the tag type is 
Ec vil'anbeee 


leaf cvlan-id { 
type uint16 { 
range "1..4094"; 
} 


description 
"VLAN identifier."; 
} 


} 
container priority-tagged { 
when "derived-from-or-self(../type, 
+ "'vpn-common:priority-tagged')" { 
description 
"Only applies when the type of 
the tagged interface is 


'priority-tagged'."; 


} 
description 
"Priority tagged."; 
leaf tag-type { 
type identityref { 
base vpn-common:tag-type; 


default "vpn-common:c-vlan"; 
description 
"Tag type. By default, the tag type is 
SOMA x a 
} 
} 
container ging { 
when "derived-from-or-self(../type, 
+ "'vpn-common:qinq')" ( 
description 
"Only applies when the type of the 
tagged interface is ‘qing'."; 


description 
"Includes QinQ parameters."; 
leaf tag-type { 
type identityref { 
base vpn-common:tag-type; 


default "vpn-common:s-c-vlan"; 
description 
"Tag type."; 


leaf svlan-id { 
type uint16; 
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mandatory true; 
description 
"Service VLAN (S-VLAN) identifier."; 


} 
leaf cvlan-id { 
type uint16; 
mandatory true; 
description 
"Customer VLAN (C-VLAN) identifier."; 
} 


} 


choice 12-service { 
description 
"The Layer 2 connectivity service can be 
provided by indicating a pointer to an 
L2VPN or by specifying a Layer 2 tunnel 
service."; 
container 12-tunnel-service { 
description 
"Defines a Layer 2 tunnel termination. 
It is only applicable when a tunnel is 
required. The supported values are 


'pseudowire', 'vpls', and 'vxlan'. Other 
values may be defined, if needed."; 
leaf type { 


type identityref { 
base 12-tunnel-type; 
} 


description 
"Selects the tunnel termination option 
for each VPN network access."; 
} 
container pseudowire { 
when "derived-from-or-self(../type, " 
* "'pseudowire')" ( 
description 
"Only applies when the Layer 2 service 
type is 'pseudowire'."; 
description 
"Includes pseudowire termination 
parameters."; 
leaf vcid ( 
type uint32; 
description 
"Indicates a pseudowire (PW) or 
virtual circuit (VC) identifier."; 


} 
leaf far-end { 
type union { 
type uint32; 
type inet:ip-address; 


description 

"Neighbor reference."; 
reference 

"RFC 8077: Pseudowire Setup and 
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Maintenance Using the Label 


Distribution Protocol 
(LDP), Section 6.1"; 


} 


container vpls { 


} 


when "derived-from-or-self(../type, 


d "nupta y? { 
description 


"Only applies when the Layer 2 service 


type IS S vplss ai 
} 
description 
"VPLS termination parameters."; 
leaf vcid { 
type uint32; 
description 
eV. Cxadentaitste acs: 


} 
leaf-list far-end { 
type union { 
type uint32; 
type inet:ip-address; 


description 
"Neighbor reference."; 


} 


container vxlan { 
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when "derived-from-or-self(../type, 


+ evan ye t 
description 


"Only applies when the Layer 2 service 


type miS V lana ws 
} 
description 
"VXLAN termination parameters."; 
leaf vni-id ( 
type uint32; 
mandatory true; 
description 
"VXLAN Network Identifier (VNI)."; 


leaf peer-mode { 
type identityref { 
base vpn-common:vxlan-peer-mode; 


default "vpn-common:static-mode"; 
description 
"Specifies the VXLAN access mode. By 
default, the peer mode is set to 


'static-mode'."; 


leaf-list peer-ip-address { 
type inet:ip-address; 
description 
"List of a peer's IP addresses."; 
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} 


case 12vpn { 
leaf 12vpn-id { 
type vpn-common:vpn-id; 
description 
"Indicates the L2VPN service associated 
with an Integrated Routing and Bridging 
(IRB) interface."; 


} 


leaf 12-termination-point { 
type string; 
description 
"Specifies a reference to a local Layer 2 
termination point, such as a Layer 2 
sub-interface."; 


leaf local-bridge-reference { 
type string; 
description 
"Specifies a local bridge reference to 
accommodate, for example, implementations 
that require internal bridging. 
A reference may be a local bridge domain."; 
} 
leaf bearer-reference { 
if-feature "vpn-common:bearer-reference"; 
type string; 
description 
"This is an internal reference for the 
service provider to identify the bearer 
associated with this VPN."; 
} 
container lag-interface { 
if-feature "vpn-common:lag-interface"; 
description 
"Container for configuration of Link 
Aggregation Group (LAG) interface 
attributes."; 
leaf lag-interface-id { 
type string; 
description 
"LAG interface identifier."; 
} 


container member-link-list { 
description 
"Container for the member link list."; 
list member-link { 
key "name"; 
description 
"Member link."; 
leaf name ( 
type string; 
description 
"Member link name."; 
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} 
} 
} 
} 
container ip-connection { 
description 
"Defines IP connection parameters."; 
leaf 13-termination-point { 
type string; 
description 
"Specifies a reference to a local Layer 3 
termination point, such as a bridge domain 
interface."; 
} 
container ipv4 { 
if-feature "vpn-common:ipv4"; 
description 
"IPv4-specific parameters." ; 
leaf local-address { 
type inet:ipv4-address; 
description 
"The IP address used at the provider's 
interface."; 


} 
leaf prefix-length { 
type uint8 { 
range "@..32"; 
} 
description 
"Subnet prefix length expressed in bits. 
It is applied to both local and customer 
addresses."; 


leaf address-allocation-type { 

type identityref { 
base address-allocation-type; 

} 

must "not(derived-from-or-self(current(), 
+ ""slaac') or " 
+ "derived-from-or-self(current(), 
+ "'provider-dhcp-slaac'))" { 
error-message "SLAAC is only applicable 

+ "to IPv6."; 


description 
"Defines how addresses are allocated to 
the peer site. 


If there is no value for the address 
allocation type, then IPv4 addressing 
is not enabled."; 


choice allocation-type { 
description 
"Choice of the IPv4 address allocation."; 
case provider-dhcp { 
description 
"Parameters related to DHCP-allocated 
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addresses. IP addresses are allocated 
by DHCP, which is provided by the 
operator."; 

leaf dhcp-service-type { 

type enumeration { 

enum server ( 

description 
"Local DHCP server."; 


enum relay { 
description 
"Local DHCP relay. DHCP requests 
are relayed to a provider's 
server."; 
} 
} 
description 
"Indicates the type of DHCP service to 
be enabled on this access."; 
} 
choice service-type { 
description 
"Choice based on the DHCP service 
typer; 
case relay { 
description 
"Container for a list of the 
provider's DHCP servers (i.e., 
'dhcp-service-type' is set to 
'relay')."; 
leaf-list server-ip-address { 
type inet:ipv4-address; 
description 
"IPv4 addresses of the provider's 
DHCP server, for use by the local 
DHCP relay."; 
} 
} 
case server { 
description 
"A choice for how addresses are 
assigned when a local DHCP server 
is enabled."; 
choice address-assign { 
default "number"; 
description 
"A choice for how IPv4 addresses 
are assigned."; 
case number { 
leaf number-of-dynamic-address { 
type uint16; 
defaults: 
description 
"Specifies the number of IP 
addresses to be assigned to 
the customer on this 
access."; 
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} 
case explicit { 
container customer-addresses { 
description 
"Container for customer 
addresses to be allocated 
using DHCP."; 
list address-pool { 
key "pool-id'; 
description 
"Describes IP addresses to 
be allocated by DHCP. 


When only 'start-address' 
is present, it represents a 
single address. 


When both 'start-address' 
and 'end-address' are 
specified, it implies a 
range inclusive of both 
addresses."; 
leaf pool-id { 
type string; 
description 
"A pool identifier for the 
address range from 
'start-address' to 


'end-address'."; 


leaf start-address ( 
type inet:ipv4-address; 
mandatory true; 
description 
"Indicates the first 
address in the pool."; 


leaf end-address ( 
type inet:ipv4-address; 
description 
"Indicates the last 
address in the pool."; 


} 
case dhcp-relay { 
description 
"The DHCP relay is provided by the 
operator."; 
container customer-dhcp-servers { 
description 
"Container for a list of the 
customer's DHCP servers."; 
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leaf-list server-ip-address { 
type inet:ipv4-address; 
description 
"IPv4 addresses of the customer's 
DHCP server."; 
} 
} 


case static-addresses { 

description 
"Lists the IPv4 addresses that are 
used."; 

leaf primary-address { 
type leafref { 

path "../address/address-id"; 

} 


description 


"Primary address of the connection."; 


list address { 
key "address-id"; 
description 
"Lists the IPv4 addresses that are 
used."; 
leaf address-id { 
type string; 
description 
"An identifier of the static IPv4 
address."; 


leaf customer-address { 
type inet:ipv4-address; 
description 
"IPv4 address of the customer 
side."; 
} 
} 
} 
} 
} 
container ipv6 { 
if-feature "vpn-common:ipv6"; 
description 
"IPv6-specific parameters."; 
leaf local-address { 
type inet:ipv6-address; 
description 
"IPv6 address of the provider side."; 


} 
leaf prefix-length { 
type uint8 { 
range "@..128"; 


description 
"Subnet prefix length expressed in bits. 


It is applied to both local and customer 


addresses."; 
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leaf address-allocation-type { 

type identityref { 
base address-allocation-type; 

} 

description 
"Defines how addresses are allocated. 
If there is no value for the address 
allocation type, then IPv6 addressing is 
disabled." ; 


choice allocation-type { 
description 
"A choice based on the IPv6 allocation 
DUDEN 
container provider-dhcp { 
when "derived-from-or-self(../address-allo" 
* "cation-type, 'provider-dhcp') or " 
* "derived-from-or-self(../address-allo" 


* "cation-type, 'provider-dhcp-slaac')" ( 


description 
"Only applies when addresses are 
allocated by DHCPv6 as provided by 
the operator."; 


} 

description 
"Parameters related to DHCP-allocated 
addresses."; 


leaf dhcp-service-type { 
type enumeration { 
enum server { 
description 
"Local DHCPv6 server."; 


enum relay { 
description 
"DHCPv6 relay."; 


} 
} 
description 
"Indicates the type of the DHCPv6 
service to be enabled on this 
access." ; 
} 
choice service-type { 
description 
"Choice based on the DHCPv6 service 
ty pera 


case relay { 
leaf-list server-ip-address { 
type inet:ipv6-address; 
description 
"IPv6 addresses of the provider's 
DHCPv6 server."; 
} 
} 
case server { 
choice address-assign { 
default "number"; 
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description 
"Choice for how IPv6 prefixes are 
assigned by the DHCPv6 server."; 
case number { 
leaf number-of-dynamic-address { 
type uint16; 
default "1"; 
description 
"Describes the number of IPv6 
prefixes that are allocated 
to the customer on this 
access."; 
} 
} 
case explicit { 
container customer-addresses { 
description 
"Container for customer IPv6 
addresses allocated by 
DHCPv6."; 
list address-pool { 
key "pool-id"; 
description 
"Describes IPv6 addresses 
allocated by DHCPv6. 


When only 'start-address' 
is present, it represents a 
single address. 


When both 'start-address' 
and 'end-address' are 
specified, it implies a 
range inclusive of both 
addresses."'; 
leaf pool-id { 
type string; 
description 
"A pool identifier for the 
address range from 
'start-address' to 


'end-address'."; 


leaf start-address { 
type inet:ipv6-address; 
mandatory true; 
description 
"Indicates the first 
address."; 


leaf end-address ( 
type inet:ipv6-address; 
description 
"Indicates the last 
address."; 
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} 
} 
} 
} 


} 
case dhcp-relay { 
description 
"DHCPv6 relay provided by the 
operator."; 
container customer-dhcp-servers { 
description 
"Container for a list of the 
customer's DHCP servers."; 
leaf-list server-ip-address { 
type inet:ipv6-address; 
description 
"Contains the IP addresses of the 
customer's DHCPv6 server."; 


} 
} 
} 
case static-addresses { 
description 
"IPv6-specific parameters for static 
allocation."; 
leaf primary-address { 
type leafref { 
path "../address/address-id"; 


description 
"Principal address of the 
connection."; 


list address { 

key "address-id"; 

description 
"Describes IPv6 addresses that are 
used."; 

leaf address-id { 
type string; 
description 


"An identifier of an IPv6 address."; 


leaf customer-address { 
type inet:ipv6-address; 
description 
"An IPv6 address of the customer 
side."; 


container routing-protocols { 
description 
"Defines routing protocols."; 
list routing-protocol { 
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key "id"; 
description 
"List of routing protocols used on the 


CE-PE link. This list can be augmented."; 


leaf id ( 
type string; 
description 
"Unique identifier for the routing 
protocol."; 


} 
leaf type { 
type identityref { 
base vpn-common:routing-protocol-type; 
} 
description 
"Type of routing protocol."; 
} 
list routing-profiles { 
key "id"; 
description 
"Routing profiles."; 
leaf id ( 
type leafref ( 
path "/13vpn-ntw/vpn-profiles" 
* "/valid-provider-identifiers" 
+ "/routing-profile-identifier/id"; 
} 
description 
"Routing profile to be used."; 


} 
leaf type { 
type identityref { 
base vpn-common:ie-type; 


description 
"Import, export, or both."; 
} 
j 


container static { 
when "derived-from-or-self(../type, 
+ "'vpn-common:static-routing' )" 
description 
"Only applies when the protocol is a 
static routing protocol."; 


} 
description 
"Configuration specific to static 
routing."; 
container cascaded-lan-prefixes { 
description 
"LAN prefixes from the customer."; 
list ipv4-lan-prefixes { 
if-feature "vpn-common:ipv4"; 
key "lan next-hop"; 
description 


"List of LAN prefixes for the site."; 


leaf lan { 
type inet:ipv4-prefix; 
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description 
"LAN prefixes."; 


} 
leaf lan-tag { 
type string; 
description 
"Internal tag to be used in VPN 
policies."; 


leaf next-hop { 
type union { 
type inet:ip-address; 
type predefined-next-hop; 


description 
"The next hop that is to be used 
for the static route. This may be 
specified as an IP address or a 
predefined next-hop type (e.g., 
‘discard’ or ‘local-link’)."; 


} 
leaf bfd-enable { 
if-feature "vpn-common:bfd"; 
type boolean; 
description 
"Enables Bidirectional Forwarding 
Detection (BFD)."; 


leaf metric { 
type uint32; 
description 
"Indicates the metric associated 
with the static route."; 


leaf preference ( 
type uint32; 
description 
"Indicates the preference associated 
with the static route."; 
} 
uses vpn-common:service-status; 
} 
list ipv6-lan-prefixes { 
if-feature "vpn-common:ipv6"; 
key "lan next-hop"; 
description 
"List of LAN prefixes for the site."; 
leaf lan { 
type inet:ipv6-prefix; 
description 
"LAN prefixes."; 


} 
leaf lan-tag { 
type string; 
description 
"Internal tag to be used in VPN 
policies."; 
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leaf next-hop { 
type union { 
type inet:ip-address; 
type predefined-next-hop; 


description 
"The next hop that is to be used for 
the static route. This may be 
specified as an IP address or a 
predefined next-hop type (e.g., 
'discard' or 'local-link')."; 


} 
leaf bfd-enable { 
if-feature "vpn-common:bfd"; 
type boolean; 
description 
"Enables BFD."; 


leaf metric { 
type uint32; 
description 
"Indicates the metric associated 
with the static route."; 


leaf preference ( 
type uint32; 
description 
"Indicates the preference associated 
with the static route."; 


uses vpn-common:service-status; 
} 
} 
} 
container bgp { 
when "derived-from-or-self(../type, " 


+ vpn-common:bgp-routing')" { 
description 
"Only applies when the protocol is 
BGP."; 
} 
description 


"Configuration specific to BGP."; 
leaf description { 
type string; 
description 
"Includes a description of the BGP 
session. 


This description is meant to be used 
for diagnostic purposes. The semantic 
of the description is local to an 
implementation."; 


leaf local-as { 
type inet:as-number; 
description 
"Indicates a local AS Number (ASN), if 
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an ASN distinct from the ASN configured 
at the VPN node level is needed."; 
} 
leaf peer-as { 
type inet:as-number; 
mandatory true; 
description 
"Indicates the customer's ASN when 
the customer requests BGP routing."; 


} 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 


} 

description 
"This node contains the address families 
to be activated.  'dual-stack' means 
that both IPv4 and IPv6 will be 
activated."; 


leaf local-address { 

type union { 
type inet:ip-address; 
type if:interface-ref; 

} 

description 
"Sets the local IP address to use for 
the BGP transport session. This may be 
expressed as either an IP address or a 


reference to an interface."; 


} 
leaf-list neighbor { 
type inet:ip-address; 
description 
"IP address(es) of the BGP neighbor. 
IPv4 and IPv6 neighbors may be 
indicated if two sessions will be used 
for IPv4 and IPv6."; 


} 
leaf multihop { 
type uint8; 
description 
"Describes the number of IP hops allowed 
between a given BGP neighbor and 
the PE? 


leaf as-override { 

type boolean; 

default "false"; 

description 
"Defines whether ASN override is 
enabled, i.e., replacing the ASN of 
the customer specified in the AS_PATH 
attribute with the local ASN."; 


leaf allow-own-as { 


type uint8; 
default "0"; 
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description 
"If set, specifies the maximum number of 
occurrences of the provider's ASN that 
are permitted within the AS. PATH 
before it is rejected."; 

} 
leaf prepend-global-as { 

type boolean; 

default "false"; 

description 
"In some situations, the ASN that is 
provided at the VPN node level may be 
distinct from the ASN configured at the 
VPN network access level. When such 
ASNs are provided, they are both 
prepended to the BGP route updates 
for this access. To disable that 
behavior, 'prepend-global-as' 
must be set to 'false'. In such a 
case, the ASN that is provided at 
the VPN node level is not prepended 
to the BGP route updates for 
this access."; 


leaf send-default-route ( 

type boolean; 

default "false"; 

description 
"Defines whether default routes can be 
advertised to a peer. If set, the 
default routes are advertised to a 
peer."; 


leaf site-of-origin { 


when "../address-family = 'vpn-common:ipv4' 
* "or 'vpn-common:dual-stack'" ( 
description 
"Only applies if IPv4 is activated."; 
} 
type rt-types:route-origin; 
description 


"The Site of Origin attribute is encoded 

as a Route Origin Extended Community. 

It is meant to uniquely identify the 

set of routes learned from a site via a 

particular CE-PE connection and is used 

to prevent routing loops."; 

reference 

"RFC 4364: BGP/MPLS IP Virtual Private 

Networks (VPNs), Section 7"; 


} 
leaf ipv6-site-of-origin { 
when "../address-family = 'vpn-common:ipv6' 
+ "or 'vpn-common:dual-stack'" { 
description 


"Only applies if IPv6 is activated."; 
} 


type rt-types:ipv6-route-origin; 


Barguil, et al. Standards Track 


Page 84 


RFC 9182 L3NM YANG Data Model 


description 
"The IPv6 Site of Origin attribute is 
encoded as an IPv6 Route Origin 
Extended Community. It is meant to 
uniquely identify the set of routes 
learned from a site via VRF 
information."; 
reference 
"RFC 5701: IPv6 Address Specific BGP 
Extended Community 
Attribute"; 


list redistribute-connected { 
key "address-family"; 
description 
"Indicates, per address family, the 
policy to follow for connected 
routes."; 
leaf address-family { 
type identityref ( 
base vpn-common:address-family; 


description 
"Indicates the address family."; 


} 
leaf enable { 
type boolean; 
description 
"Enables the redistribution of 
connected routes."; 
} 
} 


container bgp-max-prefix { 
description 
"Controls the behavior when a prefix 
maximum is reached."; 
leaf max-prefix { 
type uint32; 
default "5000"; 
description 
"Indicates the maximum number of BGP 
prefixes allowed in the BGP session. 


It allows control of how many 
prefixes can be received from a 
neighbor. 


If the limit is exceeded, the action 
indicated in 'violate-action' will be 


followed."; 
reference 


"RFC 4271: A Border Gateway Protocol 4 


(BGP-4), Section 8.2.2"; 
} 
leaf warning-threshold { 
type decimal64 { 
fraction-digits 5; 
range "@..100"; 
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} 

units "percent"; 

default "75": 

description 
"When this value is reached, a warning 
notification will be triggered."; 


leaf violate-action { 
type enumeration { 
enum warning { 
description 
"Only a warning message is sent to 
the peer when the limit is 


exceeded."; 
} 
enum discard-extra-paths { 
description 
"Discards extra paths when the 
limit is exceeded."; 
} 
enum restart { 
description 
"The BGP session restarts after 
the indicated time interval."; 
} 
} 
description 


"If the BGP neighbor 'max-prefix' 
limit is reached, the action 
indicated in 'violate-action' 
will be followed."; 


leaf restart-timer { 
type uint32; 
units "seconds"; 
description 
"Time interval after which the BGP 
session will be reestablished."; 


} 
} 


container bgp-timers { 
description 
"Includes two BGP timers that can be 
customized when building a VPN service 
with BGP used as the CE-PE routing 
protocol."; 
leaf keepalive { 
type uint16 { 
range "@..21845"; 
} 
units "seconds"; 
default "30"; 
description 
"This timer indicates the KEEPALIVE 
messages' frequency between a PE 
and a BGP peer. 


If set to '0', it indicates that 
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KEEPALIVE messages are disabled. 


It is suggested that the maximum 
time between KEEPALIVE messages be 
one-third of the Hold Time 
interval."; 
reference 
"RFC 4271: A Border Gateway Protocol 4 
(BGP-4), Section 4.4"; 


} 
leaf hold-time { 
type uint16 { 
range "@ | 3..65535"; 
} 


units "seconds"; 

default "90": 

description 
"Indicates the maximum number of 
seconds that may elapse between the 
receipt of successive KEEPALIVE 
and/or UPDATE messages from the peer. 


The Hold Time must be either zero or 
at least three seconds."; 
reference 
"RFC 4271: A Border Gateway Protocol 4 
(BGP-4), Section 4.2"; 
} 
} 
container authentication { 
description 
"Container for BGP authentication 
parameters between a PE and a CE."; 
leaf enable ( 
type boolean; 
default "false"; 
description 
"Enables or disables authentication."; 


} 

container keying-material { 
when "../enable = 'true'"; 
description 


"Container for describing how a BGP 
routing session is to be secured 
between a PE and a CE."; 

choice option { 
description 
"Choice of authentication options."; 
case ao ( 
description 
"Uses the TCP Authentication 
Option (TCP-AO)."; 
reference 
"RFC 5925: The TCP Authentication 
Option"; 
leaf enable-ao { 
type boolean; 
description 
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"Enables the TCP-AO."; 


leaf ao-keychain { 
type key-chain:key-chain-ref; 
description 
"Reference to the TCP-AO key 
chain."; 
reference 
"RFC 8177: YANG Data Model for 
Key Chains"; 
} 


case md5 { 
description 
"Uses MD5 to secure the session."; 
reference 
"RFC 4364: BGP/MPLS IP Virtual 
Private Networks 
(VPNs), Section 13.2"; 
leaf md5-keychain { 
type key-chain:key-chain-ref; 


description 
"Reference to the MD5 key 
chadnss; 

reference 
"RFC 8177: YANG Data Model for 


Key Chains"; 
} 
} 
case explicit { 
leaf key-id { 
type uint32; 
description 
"Key identifier."; 


} 
leaf key { 
type string; 
description 
"BGP authentication key. 
This model only supports the 
subset of keys that are 
representable as ASCII 
strings." ; 


leaf crypto-algorithm { 
type identityref { 
base key-chain:crypto-algorithm; 


description 
"Indicates the cryptographic 
algorithm associated with the 
key." ; 
} 
} 
case ipsec { 
description 
"Specifies a reference to an 
Internet Key Exchange Protocol 
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(IKE) Security Association 
(SA). "; 
leaf sa ( 
type string; 
description 
"Indicates the 
administrator-assigned name 
of the SA s 
} 
} 
} 
} 
} . 
uses vpn-common:service-status; 
} 
container ospf { 
when "derived-from-or-self(../type, 


* "'vpn-common:ospf-routing')" ( 
description 
"Only applies when the protocol is 
OSPEA as: 
} 
description 


"Configuration specific to OSPF."; 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 
} 


description 
"Indicates whether IPv4, IPv6, or 
both are to be activated."; 


leaf area-id { 
type yang:dotted-quad; 
mandatory true; 
description 
"Area ID."; 
reference 
"RFC 4577: OSPF as the Provider/Customer 
Edge Protocol for BGP/MPLS IP 
Virtual Private Networks 
(VPNs), Section 4.2.3 
RFC 6565: OSPFv3 as a Provider Edge to 
Customer Edge (PE-CE) Routing 
Protocol, Section 4.2"; 


leaf metric { 
type uint16; 
default "1"; 
description 
"Metric of the PE-CE link. It is used 
in the routing state calculation and 
path selection."; 


container sham-links { 
if-feature "vpn-common:rtg-ospf-sham-link"; 
description 
"List of sham links."; 
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reference 
"RFC 4577: OSPF as the Provider/Customer 
Edge Protocol for BGP/MPLS IP 
Virtual Private Networks 
(VPNs), Section 4.2.7 
RFC 6565: OSPFv3 as a Provider Edge to 
Customer Edge (PE-CE) Routing 
Protocol, Section 5"; 
list sham-link { 
key "target-site"; 
description 
"Creates a sham link with another 
Sisters 
leaf target-site { 
type string; 
description 
"Target site for the sham link 
connection. The site is referred 
to by its identifier."; 


leaf metric { 
type uint16; 
default "1"; 
description 
"Metric of the sham link. It is 
used in the routing state 
calculation and path selection. 
The default value is set to '1'."; 
reference 
"RFC 4577: OSPF as the 
Provider/Customer Edge 
Protocol for BGP/MPLS IP 
Virtual Private Networks 
(VPNs), Section 4.2.7.3 
RFC 6565: OSPFv3 as a Provider Edge 
to Customer Edge (PE-CE) 
Routing Protocol, 
Section 5.2"; 
} 
} 


leaf max-1sa { 
type uint32 { 
range "1..4294967294"; 


description 
"Maximum number of allowed Link State 
Advertisements (LSAs) that the OSPF 
instance will accept."; 
} 
container authentication { 
description 
"Authentication configuration."; 
leaf enable { 
type boolean; 
default "false"; 
description 
"Enables or disables authentication." 
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} 
container keying-material { 
when "../enable = ‘true'"; 
description 
"Container for describing how an OSPF 
session is to be secured between a CE 
and a PE."; 
choice option { 
description 
"Options for OSPF authentication."; 
case auth-key-chain { 
leaf key-chain { 
type key-chain:key-chain-ref; 
description 
"Name of the key chain."; 
} 
} 
case auth-key-explicit { 
leaf key-id { 
type uint32; 
description 
"Key identifier."; 
} 
leaf key { 
type string; 
description 
"OSPF authentication key. 
This model only supports the 
subset of keys that are 
representable as ASCII 
strings."; 
leaf crypto-algorithm { 
type identityref { 
base key-chain:crypto-algorithm; 
description 
"Indicates the cryptographic 
algorithm associated with the 
key."; 
} 
} 
case ipsec { 
leaf sa { 
type string; 
description 
"Indicates the 
administrator-assigned name 
of the Sheu 
reference 
"RFC 4552: Authentication/ 
Confidentiality for 
OSPFv3"; 
} 
} 
} 
} 
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uses vpn-common:service-status; 


} 


container isis { 
when "derived-from-or-self(../type, " 


+ vpn-common:isis-routing')" { 
description 
"Only applies when the protocol is 
TS = Se u 
} 
description 


"Configuration specific to IS-IS."; 
leaf address-family { 

type identityref { 
base vpn-common:address-family; 

} 

description 
"Indicates whether IPv4, IPv6, or both 
are to be activated."; 


leaf area-address { 
type area-address; 
mandatory true; 
description 
"Area address."; 


} 
leaf level { 
type identityref { 
base vpn-common:isis-level; 


description 
"Can be 'level-1', 'level-2', or 
'level-1-2'."; 
reference 
"RFC 9181: A Common YANG Data Model for 
Layer 2 and Layer 3 VPNs"; 


leaf metric ( 
type uint16; 
default "1"; 
description 
"Metric of the PE-CE link. It is used 
in the routing state calculation and 
path selection."; 


} 
leaf mode { 
type enumeration { 
enum active { 
description 
"The interface sends or receives 
IS-IS protocol control packets."; 


} 
enum passive { 
description 
"Suppresses the sending of IS-IS 
updates through the specified 
interface."; 
} 
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default "active"; 
description 
"IS-IS interface mode type."; 
} 


container authentication { 
description 
"Authentication configuration."; 
leaf enable { 
type boolean; 
default "false"; 
description 
"Enables or disables authentication."; 
} 
container keying-material { 
when "../enable = 'true'"; 
description 
"Container for describing how an IS-IS 
session is to be secured between a CE 
and a PE."; 
choice option { 
description 
"Options for IS-IS authentication."; 
case auth-key-chain { 
leaf key-chain { 
type key-chain:key-chain-ref; 
description 
"Name of the key chain."; 
} 
} 


case auth-key-explicit { 
leaf key-id { 
type uint32; 
description 
"Key identifier."; 


} 
leaf key { 
type string; 
description 
"IS-IS authentication key. 
This model only supports the 
subset of keys that are 
representable as ASCII 
strings." ; 


leaf crypto-algorithm { 
type identityref { 
base key-chain:crypto-algorithm; 


description 
"Indicates the cryptographic 
algorithm associated with the 
key." ; 
) 
) 
) 
) 
) 


uses vpn-common:service-status; 
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} 
container rip { 
when "derived-from-or-self(../type, 
+ "'vpn-common:rip-routing')" { 
description 
"Only applies when the protocol is RIP. 
For IPv4, the model assumes that RIP 
version 2 is used."; 
} 
description 
"Configuration specific to RIP routing."; 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 
} 
description 
"Indicates whether IPv4, IPv6, or both 
address families are to be activated."; 
} 
container timers { 
description 
"Indicates the RIP timers."; 
reference 
"RFC 2453: RIP Version 2"; 
leaf update-interval { 
type uint16 { 
range "1..32767"; 
} 


units "seconds"; 

default "30"; 

description 
"Indicates the RIP update time, i.e., 
the amount of time for which RIP 
updates are sent."; 


leaf invalid-interval { 
type uint16 { 
range "1..32767"; 
} 
units "seconds"; 
default "180"; 
description 
"The interval before a route is 
declared invalid after no updates are 
received. This value is at least 
three times the value for the 
'update-interval' argument." ; 


leaf holddown-interval { 
type uint16 { 
range "1..32767"; 
} 
units "seconds"; 
default "180"; 
description 
"Specifies the interval before better 
routes are released."; 
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leaf flush-interval ( 

type uint16 { 
range "1..32767"; 

} 

units "seconds"; 

default "240"; 

description 
"Indicates the RIP flush timer, i.e., 
the amount of time that must elapse 
before a route is removed from the 
routing table."; 


} 


} 
leaf default-metric { 
type uint8 { 
range "@..16"; 


} 
default "1"; 
description 
"Sets the default metric."; 
} 


container authentication { 
description 
"Authentication configuration."; 
leaf enable { 
type boolean; 
default "false"; 
description 
"Enables or disables authentication."; 


} 

container keying-material { 
when "../enable = ‘true'"; 
description 


"Container for describing how a RIP 
session is to be secured between a CE 
and a PE."; 

choice option { 
description 
"Specifies the authentication 
scheme."; 
case auth-key-chain { 
leaf key-chain { 
type key-chain:key-chain-ref; 
description 
"Name of the key chain."; 
} 
} 
case auth-key-explicit { 
leaf key { 
type string; 
description 
"RIP authentication key. 
This model only supports the 
subset of keys that are 
representable as ASCII 
strings."; 


leaf crypto-algorithm { 
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type identityref { 
base key-chain:crypto-algorithm; 

} 

description 
"Indicates the cryptographic 
algorithm associated with the 
key."; 

} 
} 
} 
} 
} 


uses vpn-common:service-status; 


container vrrp { 


when "derived-from-or-self(../type, 
* "'vpn-common:vrrp-routing')" ( 
description 
"Only applies when the protocol is the 
Virtual Router Redundancy Protocol 
(VRRP)."; 


description 
"Configuration specific to VRRP."; 
reference 
"RFC 5798: Virtual Router Redundancy 
Protocol (VRRP) Version 3 for 
IPv4 and IPv6"; 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 


description 
"Indicates whether IPv4, IPv6, or both 
address families are to be enabled."; 
} 
leaf vrrp-group { 
type uint8 { 
range "1..255"; 
} 


description 
"Includes the VRRP group identifier."; 


} 
leaf backup-peer { 
type inet:ip-address; 
description 
"Indicates the IP address of the peer."; 


leaf-list virtual-ip-address { 
type inet:ip-address; 
description 
"Virtual IP addresses for a single VRRP 
group."; 
reference 
"RFC 5798: Virtual Router Redundancy 
Protocol (VRRP) Version 3 for 
IPv4 and IPv6, 
Sections 1.2 and 1.3"; 
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} 
leaf priority { 
type uint8 { 
range "1..254"; 


} 

default "100"; 

description 
"Sets the local priority of the VRRP 
speaker."; 


} 
leaf ping-reply { 
type boolean; 
default "false"; 
description 
"Controls whether the VRRP speaker 
should reply to ping requests."; 
} 
uses vpn-common:service-status; 
} 
} 
} 
container oam { 
description 
"Defines the Operations, Administration, 
and Maintenance (OAM) mechanisms used. 


BFD is set as a fault detection mechanism, 
but other mechanisms can be defined in the 
future. ess 
container bfd ( 

if-feature "vpn-common:bfd"; 
description 

"Container for BFD."; 
leaf session-type { 

type identityref { 

base vpn-common:bfd-session-type; 


default "vpn-common:classic-bfd"; 
description 
"Specifies the BFD session type."; 


leaf desired-min-tx-interval { 
type uint32; 
units "microseconds"; 
default "1000000"; 
description 
"The minimum interval between 
transmissions of BFD Control packets, 
desired by the operator."; 
reference 
"RFC 5880: Bidirectional Forwarding 
Detection (BFD), 
Section 6.8.7"; 
} 
leaf required-min-rx-interval { 
type uint32; 
units "microseconds"; 
default "1900000"; 
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description 
"The minimum interval between received BFD 
Control packets that the PE should 
support."; 
reference 
"RFC 5880: Bidirectional Forwarding 
Detection (BFD), 
Section 6.8.7"; 


leaf local-multiplier { 
type uint8 { 
range "1..255"; 


} 

default "3"; 

description 
"Specifies the detection multiplier that 
is transmitted to a BFD peer. 


The detection interval for the receiving 
BFD peer is calculated by multiplying the 
value of the negotiated transmission 
interval by the received detection 
multiplier value."; 
reference 
"RFC 5880: Bidirectional Forwarding 
Detection (BFD), 
Section 6.8.7"; 


} 
leaf holdtime { 
type uint32; 
units "milliseconds"; 
description 
"Expected BFD holdtime. 


The customer may impose some fixed 
values for the holdtime period if the 
provider allows the customer to use 
this function. 


If the provider doesn't allow the 
customer to use this function, 
fixed values will not be set."; 
reference 
"RFC 5880: Bidirectional Forwarding 
Detection (BFD), 
Section 6.8.18"; 


} 
leaf profile { 
type leafref { 
path "/13vpn-ntw/vpn-profiles" 
+ "/valid-provider-identifiers" 
+ "/bfd-profile-identifier/id"; 
} 
description 
"Well-known service provider profile name. 


The provider can propose some profiles 
to the customer, depending on the 
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service level the customer wants to 
achieve."; 
} 
container authentication { 
presence "Enables BFD authentication"; 
description 
"Parameters for BFD authentication." ; 
leaf key-chain { 
type key-chain:key-chain-ref; 
description 
"Name of the key chain."; 
} 
leaf meticulous { 
type boolean; 
description 
"Enables meticulous mode."; 
reference 
"RFC 5880: Bidirectional Forwarding 
Detection (BFD), 
Section 6.7"; 
} 
} . 
uses vpn-common:service-status; 
} 
} 
container security { 
description 
"Site-specific security parameters."; 
container encryption { 
if-feature "vpn-common:encryption'; 
description 
"Container for CE-PE security encryption."; 
leaf enabled { 
type boolean; 
default "false"; 
description 
"If set to 'true', traffic encryption on 
the connection is required. Otherwise, 
it is disabled."; 


} 
leaf layer { 
when "../enabled = 'true'" { 
description 
"Included only when encryption 
is enabled."; 
} 
type enumeration { 
enum layer2 { 
description 
"Encryption occurs at Layer 2."; 


enum layer3 { 
description 
"Encryption occurs at Layer 3. 
For example, IPsec may be used when 
a customer requests Layer 3 
encryption."; 
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} 

description 
"Indicates the layer on which encryption 
is applied."; 


} 
container encryption-profile { 
when "../encryption/enabled = 'true'" ( 
description 
"Indicates the layer on which encryption 
is enabled."; 
} 
description 
"Container for the encryption profile."; 
choice profile { 
description 
"Choice for the encryption profile."; 
case provider-profile { 
leaf profile-name { 
type leafref ( 
path "/13vpn-ntw/vpn-profiles" 
* "/valid-provider-identifiers" 
* "/encryption-profile-identifier/id"; 
} 
description 
"Name of the service provider's 
profile to be applied."; 
} 
} 


case customer-profile { 
leaf customer-key-chain { 
type key-chain:key-chain-ref; 
description 
"Customer-supplied key chain."; 
} 
} 
} 
} 
} 
container service { 
description 
"Service parameters of the attachment."; 
leaf pe-to-ce-bandwidth { 
if-feature "vpn-common:inbound-bw" ; 
type uint64; 
units "bps"; 
description 
"From the customer site's perspective, the 
service inbound bandwidth of the connection 
or download bandwidth from the SP to the 
site. Note that the L3SM uses 
'input-bandwidth' to refer to the same 
concept."; 
} 
leaf ce-to-pe-bandwidth { 
if-feature "vpn-common:outbound-bw" ; 
type uint64; 
units "bps"; 
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description 
"From the customer site's perspective, 
the service outbound bandwidth of the 
connection or upload bandwidth from 
the site to the SP. Note that the L3SM 
uses 'output-bandwidth' to refer to the 
same concept."; 


} 
leaf mtu { 
type uint32; 
units "bytes"; 
description 
"MTU at the service level. If the service 
is IP, it refers to the IP MTU. If 
Carriers' Carriers (CsC) is enabled, the 
requested MTU will refer to the MPLS 
maximum labeled packet size and not to the 
IP MTU."; 
} 
container qos { 
if-feature "vpn-common:gos"; 
description 
"QoS configuration."; 
container qos-classification-policy { 
description 
"Configuration of the traffic 
classification policy."; 
uses vpn-common:qos-classification-policy; 


container qos-action { 
description 
"List of QoS action policies."; 
list rule ( 
key "id"; 
description 
HERS CEON LOOS TAIC ECTLONS A a 
leaf id { 
type string; 
description 
"An identifier of the QoS action 
rule."; 


leaf target-class-id { 
type string; 
description 
"Identification of the class of 
service. This identifier is internal 
to the administration."; 


leaf inbound-rate-limit ( 
type decimal64 { 
fraction-digits 5; 
range "@..100"; 


units "percent"; 

description 
"Specifies whether/how to rate-limit 
the inbound traffic matching this QoS 
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policy. It is expressed as a percent 
of the value that is indicated in 
'input-bandwidth'."; 
leaf outbound-rate-limit { 
type decimal64 { 
fraction-digits 5; 
range "@..100"; 


units "percent"; 
description 
"Specifies whether/how to rate-limit 
the outbound traffic matching this 
QoS policy. It is expressed as a 
percent of the value that is 
indicated in 'output-bandwidth'."; 
} 
} 
} 
container qos-profile { 
description 
"QoS profile configuration."; 
list qos-profile { 
key "profile"; 
description 
"QoS profile. 
Can be a standard profile or 
a customized profile."; 
leaf profile ( 
type leafref ( 
path "/13vpn-ntw/vpn-profiles" 
* "/valid-provider-identifiers" 
+ "/qos-profile-identifier/id"; 
i 
description 
"QoS profile to be used."; 


leaf direction { 
type identityref { 
base vpn-common:qos-profile-direction; 


default "“vpn-common:both"; 
description 
"The direction to which the QoS 
profile is applied."; 


} 
} 
} 
container carriers-carrier { 
if-feature "vpn-common:carriers-carrier"; 
description 
"This container is used when the customer 
provides MPLS-based services. This is 
only used in the case of CsC (i.e., a 
customer builds an MPLS service using an 
IP VPN to carry its traffic)."; 
leaf signaling-type { 


Barguil, et al. Standards Track Page 102 


RFC 9182 L3NM YANG Data Model 


type enumeration { 
enum ldp { 
description 
"Uses LDP as the signaling protocol 
between the PE and the CE. In this 
case, an IGP routing protocol must 
also be configured."; 


} 
enum bgp { 
description 
"Uses BGP as the signaling protocol 
between the PE and the CE. 
In this case, BGP must also be 


configured as the routing protocol."; 


reference 
"RFC 8277: Using BGP to Bind MPLS 
Labels to Address 


Prefixes"; 
} 
} 
default "bgp"; 
description 
"MPLS signaling type."; 
} 
} 
container ntp { 
description 


"Time synchronization may be needed in some 
VPNs, such as infrastructure and management 


VPNs. This container includes parameters 
to enable the NTP service."; 
reference 
"RFC 5905: Network Time Protocol Version 4: 
Protocol and Algorithms 
Specification"; 
leaf broadcast { 
type enumeration { 
enum client { 
description 
"The VPN node will listen to NTP 
broadcast messages on this VPN 
network access."; 


} 
enum server { 
description 
"The VPN node will behave as a 
broadcast server."; 
} 
} 
description 
"Indicates the NTP broadcast mode to use 
for the VPN network access."; 
} 
container auth-profile { 
description 


"Pointer to a local profile."; 
leaf profile-id { 
type string; 
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description 
"A pointer to a local authentication 
profile on the VPN node is provided."; 


} 
} H 
uses vpn-common:service-status; 
} 
container multicast { 
if-feature "vpn-common:multicast"; 
description 
"Multicast parameters for the network 
access."; 
leaf access-type { 
type enumeration { 
enum receiver-only { 
description 
"The peer site only has receivers."; 
} 


enum source-only { 
description 
"The peer site only has sources."; 
} 


enum source-receiver { 
description 
"The peer site has both sources and 
receivers."; 
default "source-receiver'; 


description 
"Type of multicast site."; 


} 
leaf address-family { 
type identityref { 
base vpn-common:address-family; 
} 
description 
"Indicates the address family."; 
} 
leaf protocol-type { 
type enumeration { 
enum host { 
description 
"Hosts are directly connected to the 
provider network. 


Host protocols, such as IGMP or MLD, 
are required."; 


enum router { 
description 
"Hosts are behind a customer router. 
PIM will be implemented."; 


enum both { 
description 
"Some hosts are behind a customer 
router, and some others are directly 
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connected to the provider network. 
Both host and routing protocols must 
be used. 


Typically, IGMP and PIM will be 
implemented."; 


} 


} 
default "both"; 
description 
"Multicast protocol type to be used with 
the customer site."; 
} 
leaf remote-source { 
type boolean; 
default "false"; 
description 
"A remote multicast source is a source 
that is not on the same subnet as the 
VPN network access. When set to ‘true’, 
the multicast traffic from a remote 
source is accepted."; 
} 
container igmp { 
when "../protocol-type = 'host' and 
+ "../address-family = 'vpn-common:ipv4' 
+ "or 'vpn-common:dual-stack'"; 
if-feature "vpn-common:igmp"; 
description 
"Includes IGMP-related parameters."; 
list static-group { 
key "group-addr"; 
description 
"Multicast static source/group 
associated with the IGMP session."; 
leaf group-addr { 
type rt-types:ipv4-multicast-group-address; 
description 
"Multicast group IPv4 address."; 


} 
leaf source-addr { 
type 
rt-types:ipv4-multicast-source-address; 
description 
"Multicast source IPv4 address."; 
} 


leaf max-groups { 
type uint32; 
description 
"Indicates the maximum number of 
groups."; 


leaf max-entries ( 
type uint32; 
description 
"Indicates the maximum number of IGMP 
entries."; 
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} 


leaf max-group-sources { 
type uint32; 
description 
"The maximum number of group sources."; 
} 


leaf version { 
type identityref { 
base vpn-common:igmp-version; 


default "vpn-common:igmpv2"; 
description 
"Indicates the IGMP version."; 


} 
uses vpn-common:service-status; 
} 
container mld { 
when "../protocol-type = 'host' and " 
+ "../address-family = 'vpn-common:ipv6' " 


+ "or 'vpn-common:dual-stack'"; 
if-feature "vpn-common:mld"; 
description 
"Includes MLD-related parameters."; 
list static-group { 
key "group-addr"; 
description 
"Multicast static source/group associated 
with the MLD session."; 
leaf group-addr { 
type rt-types:ipv6-multicast-group-address; 
description 
"Multicast group IPv6 address."; 


leaf source-addr { 
type 
rt-types:ipv6-multicast-source-address; 
description 
"Multicast source IPv6 address."; 
} 


} 
leaf max-groups { 
type uint32; 
description 
"Indicates the maximum number of 
groups."; 


leaf max-entries ( 
type uint32; 
description 
"Indicates the maximum number of MLD 
entries."; 
} 
leaf max-group-sources { 
type uint32; 
description 
"The maximum number of group sources."; 


leaf version { 
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type identityref { 
base vpn-common:mld-version; 


default "vpn-common:mldv2"; 
description 
"Indicates the MLD protocol version."; 
} 


uses vpn-common:service-status; 


container pim { 
when "../protocol-type = 'router'"; 
if-feature "vpn-common:pim"; 
description 
"Only applies when the protocol type is 
SDM ase 
leaf hello-interval { 
type rt-types:timer-value-seconds16; 
default "30"; 
description 
"Interval between PIM Hello messages. 
If set to ‘infinity’ or 'not-set', 
no periodic Hello messages are sent."; 
reference 
"RFC 7761: Protocol Independent 
Multicast - Sparse Mode 
(PIM-SM): Protocol 
Specification (Revised), 
Section 4.11 
RFC 8294: Common YANG Data Types for 
the Routing Area"; 


} 
leaf dr-priority { 
type uint32; 
default "1"; 
description 
"Indicates the preference associated 
with the DR election process. A larger 
value has a higher priority over a 
smaller value."; 
reference 
"RFC 7761: Protocol Independent 
Multicast - Sparse Mode 
(PIM-SM): Protocol 
Specification (Revised), 
Section 4.3.2"; 
} 


uses vpn-common:service-status; 
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«CODE ENDS» 


9. Security Considerations 


The YANG module specified in this document defines a schema for data that is designed to be 
accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF 
[RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to- 
implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 
and the mandatory-to-implement secure transport is TLS [RFC8446]. 


The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to 
restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all 
available NETCONF or RESTCONF protocol operations and content. 


There are a number of data nodes defined in this YANG module that are writable/creatable/ 
deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or 
vulnerable in some network environments. Write operations (e.g., edit-config) and delete 
operations to these data nodes without proper protection or authentication can have a negative 
effect on network operations. These are the subtrees and data nodes and their sensitivity/ 
vulnerability in the "ietf-IBvpn-ntw" module: 


'vpn-profiles: This container includes a set of sensitive data that influence how the L3VPN 
service is delivered. For example, an attacker who has access to these data nodes may be able 
to manipulate routing policies, QoS policies, or encryption properties. These data nodes are 
defined with "nacm:default-deny-write" tagging [RFC9181]. 


'Vpn-services: An attacker who is able to access network nodes can undertake various attacks, 
such as deleting a running L3VPN service, interrupting all the traffic of a client. In addition, an 
attacker may modify the attributes of a running service (e.g., QoS, bandwidth, routing 
protocols, keying material), leading to malfunctioning of the service and therefore to Service 
Level Agreement (SLA) violations. In addition, an attacker could attempt to create an L3VPN 
service or add a new network access. In addition to using NACM to prevent unauthorized 
access, such activity can be detected by adequately monitoring and tracking network 
configuration changes. 


Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable 
in some network environments. It is thus important to control read access (e.g., via get, get- 
config, or notification) to these data nodes. These are the subtrees and data nodes and their 
sensitivity/vulnerability: 


'customer-name' and 'ip-connection: An attacker can retrieve privacy-related information, 
which can be used to track a customer. Disclosing such information may be considered a 
violation of the customer-provider trust relationship. 
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'keying-material: An attacker can retrieve the cryptographic keys protecting the underlying 
VPN service (CE-PE routing, in particular). These keys could be used to inject spoofed routing 
advertisements. 


Several data nodes ('bgp', 'ospf', ‘isis’, rip', and 'bfd") rely upon [RFC8177] for authentication 
purposes. Therefore, this module inherits the security considerations discussed in Section 5 of 
[RFC8177]. Also, these data nodes support supplying explicit keys as strings in ASCII format. The 
use of keys in hexadecimal string format would afford greater key entropy with the same number 
of key-string octets. However, such a format is not included in this version of the L3NM, because it 
is not supported by the underlying device modules (e.g., [RFC8695]). 


As discussed in Section 7.6.3, the module supports MD5 to basically accommodate the installed 
BGP base. MD5 suffers from the security weaknesses discussed in Section 2 of [RFC6151] and 
Section 2.1 of [RFC6952]. 


[RFC8633] describes best current practices to be considered in VPNs making use of NTP. Moreover, 
a mechanism to provide cryptographic security for NTP is specified in [RFC8915]. 


10. IANA Considerations 


IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" 
[RFC3688]: 


URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 
Registrant Contact: The IESG. 
XML: N/A; the requested URI is an XML namespace. 


IANA has registered the following YANG module in the "YANG Module Names" subregistry 
[RFC6020] within the "YANG Parameters" registry. 


Name: ietf-I3vpn-ntw 

Maintained by IANA? N 

Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 
Prefix: 13nm 

Reference: RFC9182 


11. References 


11.1. Normative References 


[ISO10589] ISO, "Information technology - Telecommunications and information exchange 
between systems - Intermediate System to Intermediate System intra-domain 
routeing information exchange protocol for use in conjunction with the protocol 
for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 
10589:2002, 2002, «https://www.iso.org/standard/30932.html». 


Barguil, et al. Standards Track Page 109 


RFC 9182 


[RFC1112] 


[RFC1195] 


[RFC2080] 


[RFC2119] 


[RFC2236] 


[RFC2453] 


[RFC2710] 


[RFC3376] 


[RFC3688] 


[RFC3810] 


[RFC4271] 


[RFC4364] 


[RFC4552] 


[RFC4577] 


Barguil, et al. 


L3NM YANG Data Model February 2022 


Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/ 
RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>. 


Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 
1195, DOI 10.17487/RFC1195, December 1990, «https://www.rfc-editor.org/info/ 
rfc1195>. 


Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, DOI 10.17487/RFC2080, 
January 1997, <https://www.rfc-editor.org/info/rfc2080>. 


Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, 
RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/ 
rfc2119>. 


Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 
10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>. 


Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 
1998, <https://www.rfc-editor.org/info/rfc2453>. 


Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) 
for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc- 
editor.org/info/rfc2710>. 


Cain, B., Deering, S., Kouvelas, I., Fenner, B.,and A. Thyagarajan, "Internet Group 
Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 
<https://www.rfc-editor.org/info/rfc3376>. 


Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, 
January 2004, <https://www.rfc-editor.org/info/rfc3688>. 


Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) 
for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/ 
info/rfc3810>. 


Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", 
RFC 4271, DOI 10.17487/RFC4271, January 2006, «https://www.rfc-editor.org/info/ 
rfc4271>. 


Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 
4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/ 
rfc4364>. 


Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, 
DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>. 


Rosen, E., Psenak, P, and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge 
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 
10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>. 


Standards Track Page 110 


RFC 9182 


[RFC5308] 


[RFC5701] 


[RFC5709] 


[RFC5798] 


[RFC5880] 


[RFC5905] 


[RFC5925] 


[RFC6020] 


[RFC6241] 


[RFC6242] 


[RFC6513] 


[RFC6514] 


[RFC6565] 


[RFC6991] 


Barguil, et al. 


L3NM YANG Data Model February 2022 


Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 
2008, <https://www.rfc-editor.org/info/rfc5308>. 


Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 
5701, DOI 10.17487/RFC5701, November 2009, «https://www.rfc-editor.org/info/ 
rfc5701>. 


Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, 
"OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/ 
RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>. 


Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 
and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc- 
editor.org/info/rfc5798>. 


Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 
10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>. 


Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol 
Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/ 
RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. 


Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, 
DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>. 


Bjorklund, M, Ed., "YANG - A Data Modeling Language for the Network 
Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 
2010, <https://www.rfc-editor.org/info/rfc6020>. 


Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., 
"Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, 
June 2011, <https://www.rfc-editor.org/info/rfc6241>. 


Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, 
DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>. 


Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, 
DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>. 


Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures 
for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 
2012, <https://www.rfc-editor.org/info/rfc6514>. 


Pillay-Esnault, P, Moyer, P, Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 asa 
Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 
10.17487/RFC6565, June 2012, <https://www.rfc-editor.org/info/rfc6565>. 


Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/ 
RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. 


Standards Track Page 111 


RFC 9182 


[RFC7166] 


[RFC7474] 


[RFC7761] 


[RFC7950] 


[RFC8040] 


[RFC8174] 


[RFC8177] 


[RFC8294] 


[RFC8341] 


[RFC8343] 


[RFC8446] 


[RFC8466] 


[RFC8519] 


Barguil, et al. 


L3NM YANG Data Model February 2022 


Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for 
OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc- 
editor.org/info/rfc7166>. 


Bhatia, M., Hartman, S., Zhang, D.,and A. Lindem, Ed., "Security Extension for 
OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, 
April 2015, <https://www.rfc-editor.org/info/rfc7474>. 


Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. 
Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 
Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, 
«https://www.rfc-editor.org/info/rfc 7761». 


Bjorklund, M, Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 
10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. 


Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 
10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. 


Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, 
RFC 8174, DOI 10.17487/RFC8174, May 2017, «https://www.rfc-editor.org/info/ 
rfc8174>. 


Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key 
Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, <https://www.rfc-editor.org/ 
info/rfc8177>. 


Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for 
the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, <https:// 
www .ric-editor.org/info/rfc8294>. 


Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model’, 
STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/ 
info/rfc8341>. 


Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 
10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. 


Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, 
DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. 


Wen, B., Fioccola, G., Ed., Xie, C.,and L. Jalil, "A YANG Data Model for Layer 2 
Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/ 
RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>. 


Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for 
Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 
2019, <https://www.rfc-editor.org/info/rfc8519>. 


Standards Track Page 112 


RFC 9182 L3NM YANG Data Model February 2022 


[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, "A Common 
YANG Data Model for Layer 2 and Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, 
February 2022, <https://www.rfc-editor.org/info/rfc9181>. 


11.2. Informative References 


[BGP-YANG] Jethanandani, M, Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service 
Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp- 
model-12, 25 October 2021, «https://datatracker.ietf.org/doc/html/draft-ietf-idr- 
bgp-model-12>. 


[Enhanced-VPN-Framework] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework 
for Enhanced Virtual Private Network (VPN+) Services", Work in Progress, 
Internet-Draft, draft-ietf-teas-enhanced-vpn-09, 25 October 2021, <https:// 
datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-09>. 


[IEEE802.1AX] IEEE, "802.1AX-2020 - IEEE Standard for Local and Metropolitan Area Networks— 
Link Aggregation", IEEE Std 802.1AX-2020, <https://ieeexplore.ieee.org/document/ 
9105034>. 


[Network-Slices-Framework] Farrel, A., Ed., Gray, E., Drake, J., Rokui, R.. Homma, S., Makhijani, 
K., Contreras, LM., and J. Tantsura, "Framework for IETF Network Slices", Work 
in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 October 2021, 
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05>. 


[PIM-YANG] Liu, X., McAllister, P, Peter, A., Sivakumar, M., Liu, Y., and F. Hu, "A YANG Data 
Model for Protocol Independent Multicast (PIM)", Work in Progress, Internet- 
Draft, draft-ietf-pim-yang-17, 19 May 2018, «https://datatracker.etf.org/doc/html/ 
draft-ietf-pim-yang-17>. 


[PYANG] "pyang", commit 524cf61, December 2021, <https://github.com/mbj4668/pyang>. 


[QoS-YANG] Choudhary, A., Jethanandani, M., Aries, E.,and I. Chen, "A YANG Data Model for 
Quality of Service (QoS)", Work in Progress, Internet-Draft, draft-ietf-rtgwg-qos- 
model-06, 8 November 2021, «https://datatracker.ietf.org/doc/html/draft-ietf- 
rtgwg-qos-model-06>. 


[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", 
RFC 3618, DOI 10.17487/RFC3618, October 2003, «https://www.rfc-editor.org/info/ 
rfc3618>. 


[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of 
Service (QoS) Information Model", RFC 3644, DOI 10.17487/RFC3644, November 
2003, <https://www.rfc-editor.org/info/rfc3644>. 


[REC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network 
(VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, «https:// 
www.rfc-editor.org/info/rfc4026». 


Barguil, et al. Standards Track Page 113 


RFC 9182 


[RFC4110] 


[RFC4176] 


[RFC4862] 


[RFC6037] 


[RFC6151] 


[RFC6952] 


[RFC7149] 


[RFC7297] 


[RFC7426] 


[RFC7880] 


[RFC8077] 


[RFC8277] 


Barguil, et al. 


L3NM YANG Data Model February 2022 


Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual 
Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, <https:// 
www .rfc-editor.org/info/rfc4110>. 


El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,and A. Gonguet, 
"Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and 
Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, «https://www.rfc- 
editor.org/info/rfc4176>. 


Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", 
RFC 4862, DOI 10.17487/RFC4862, September 2007, «https://www.rfc-editor.org/ 
info/rfc4862>. 


Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco Systems' Solution for Multicast 
in BGP/MPLS IP VPNs", RFC 6037, DOI 10.17487/RFC6037, October 2010, <https:// 
www.rfc-editor.org/info/rfc6037>. 


Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message- 
Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 
2011, <https://www.rfc-editor.org/info/rfc6151>. 


Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP 
Issues According to the Keying and Authentication for Routing Protocols (KARP) 
Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, «https://www.rfc- 
editor.org/info/rfc6952>. 


Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective 
from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, 
March 2014, <https://www.rfc-editor.org/info/rfc7149>. 


Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile 
(CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/ 
info/rfc7297>. 


Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. 
Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture 
Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc- 
editor.org/info/rfc7426>. 


Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless 
Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, 
July 2016, <https://www.rfc-editor.org/info/rfc7880>. 


Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the 
Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, 
February 2017, <https://www.rfc-editor.org/info/rfc8077>. 


Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 
10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>. 


Standards Track Page 114 


RFC 9182 


[RFC8299] 


[RFC8309] 


[RFC8340] 


[RFC8342] 


[RFC8345] 


[RFC8349] 


[RFC8453] 


[RFC8512] 


[RFC8633] 


[RFC8695] 


[RFC8792] 


[RFC8915] 


[RFC8969] 


Barguil, et al. 


L3NM YANG Data Model February 2022 


Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for 
L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https:// 
www.rfc-editor.org/info/rfc8299>. 


Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/ 
RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>. 


Bjorklund, M. and L. Berger, Ed., " YANG Tree Diagrams", BCP 215, RFC 8340, DOI 
10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. 


Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network 
Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, 
March 2018, <https://www.rfc-editor.org/info/rfc8342>. 


Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A 
YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, 
March 2018, <https://www.rfc-editor.org/info/rfc8345>. 


Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management 
(NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, «https://www.rfc- 
editor.org/info/rfc8349>. 


Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE 
Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https:// 
www.rfc-editor.org/info/rfc8453>. 


Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A 
YANG Module for Network Address Translation (NAT) and Network Prefix 
Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, <https:// 
www.rfc-editor.org/info/rfc8512>. 


Reilly, D., Stenn, H., and D. Sibold, "Network Time Protocol Best Current 
Practices", BCP 223, RFC 8633, DOI 10.17487/RFC8633, July 2019, <https://www.rfc- 
editor.org/info/rfc8633>. 


Liu, X., Sarda, P, and V. Choudhary, "A YANG Data Model for the Routing 
Information Protocol (RIP)", RFC 8695, DOI 10.17487/RFC8695, February 2020, 
<https://www.rfc-editor.org/info/rfc8695>. 


Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content 
of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https:// 
www .rfc-editor.org/info/rfc8792». 


Franke, D, Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time 
Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, 
September 2020, <https://www.rfc-editor.org/info/rfc8915>. 


Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C.,and L. Geng, "A Framework for 
Automating Service and Network Management with YANG", RFC 8969, DOI 
10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/info/rfc8969>. 


Standards Track Page 115 


RFC 9182 L3NM YANG Data Model February 2022 


[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix 
Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RF C9136, 
October 2021, <https://www.rfc-editor.org/info/rfc9136>. 


[YANG-Composed-VPN] Even, R., Wu, B., Wu, Q., and Y. Cheng, "YANG Data Model for Composed 
VPN Service Delivery", Work in Progress, Internet-Draft, draft-evenwu-opsawg- 
yang-composed-vpn-03, 8 March 2019, <https://datatracker.ietf.org/doc/html/ 
draft-evenwu-opsawg-yang-composed-vpn-03>. 


[YANG-SAPs] Gonzalez de Dios, O., Barguil, S., Wu, Q., Boucadair, M., and V. Lopez, "A Network 
YANG Model for Service Attachment Points", Work in Progress, Internet-Draft, 
draft-ietf-opsawg-sap-00, 25 January 2022, «https://datatracker.ietf.org/doc/html/ 
draft-ietf-opsawg-sap-00>. 


Appendix A. L3VPN Examples 


A.1. 4G VPN Provisioning Example 


L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise services, mainly because several 
traffic discrimination policies can be applied within the network to deliver to the mobile 
customers a service that meets the SLA requirements. 


Typically, and as shown in Figure 31, an eNodeB (CE) is directly connected to the access routers of 
the mobile backhaul and their logical interfaces (one or many, according to the service type) are 
configured in a VPN that transports the packets to the mobile core platforms. In this example, a 
'Vpn-node' is created with two 'vpn-network-accesses'. 


+------------- + +------------------ + 

| | | PE | 

| | | ESSE UOS | 

| eNodeB |e-—————— [cies >| ete 

| | vlan 1m] | | 

| |B [cic me | 

| | vlan 2 | | | | 

| | Direct MEE id S ap | 

Pose Ge Hpac + Routing | | vpn-node-id | | 
les | | 
| +------------- + | 
| | 
+------------------ + 


Figure 31: Mobile Backhaul Example 
To create an L3VPN service using the L3NM, the following steps can be followed. 


First, create the 4G VPN service (Figure 32). 
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POST: /restconf/data/ietf-13vpn-ntw:l3vpn-ntw/vpn-services 
Host: example.com 
Content-Type: application/yang-datat+json 


"ietf-13vpn-ntw:vpn-services": { 
"vpn-service": [ 


"vpn-id": "AG", 


"vpn-description': "VPN to deploy 4G services", 
"customer-name": "mycustomer", 
"vpn-service-topology": "custom", 


"vpn-instance-profiles"': { 
"vpn-instance-profile": [ 


"profile-id': "simple-profile", 
"local-as": 65550, 

drdi: Os 65550 
"address-family": [ 


"address-family": "ietf-vpn-common:dual-stack", 
"vypn-targets": { 
"vpn-target": [ 


Malay? e Al, 
"route-targets': [ 


"route-target": "@:65550:1" 
} 


"route-target-type": "both" 


Figure 32: Create VPN Service 


Second, create a VPN node, as depicted in Figure 33. In this type of service, the VPN node is 
equivalent to VRF configured in the physical device (‘ne-id'=198.51.100.1). NOTE: '\' line wrapping 
in Figures 33 and 34 is implemented per [RFC8792]. 
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POST: /restconf/data/ietf-13vpn-ntw:l3vpn-ntw/V 
vpn-services/vpn-service-4G 

Host: example.com 

Content-Type: application/yang-datat+json 


"ietf-13vpn-ntw:vpn-nodes"': { 
"vpn-node": [ 
"vpn-node-id': "44", 
"ne-id": "198.51.100.1", 
"active-vpn-instance-profiles": { 


"vpn-instance-profile": [ 


"profile-id': "simple-profile" 


Figure 33: Create VPN Node 


February 2022 


Finally, two VPN network accesses are created using the same physical port (‘interface-id'=1/1/1). 
Each vpn-network-access' has a particular VLAN interface (1,2): "SYNC" and "DATA" (Figure 34). 


These interfaces differentiate the traffic between them. 
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POST: /restconf/data/ietf-13vpn-ntw:13vpn-ntw/\ 
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 
content-type: application/yang-datat+json 


"ietf-13vpn-ntw:vpn-network-accesses": { 
"vpn-network-access": [ 


Ago v3 tw 


"interface-id": "1/1/1", 

"description": "Interface SYNC to eNODE-B", 
"vpn-network-access-type": "ietf-vpn-common:point-to-point", 
"vpn-instance-profile": "simple-profile", 


"status": ( 
"admin-status": { 
"status": "ietf-vpn-common:admin-up" 
} 


onnection": { 
"encapsulation": { 


} 


"type": "ietf-vpn-common:dotiq", 
"dotiq': { 
"cvlan-id"': 1 
} 
} 
Pe 
"ip-connection"': { 
DV t 
"local-address": "192.0.2.1", 
"prefix-length": 30, 
"address-allocation-type": "static-address", 
"static-addresses": { 
"primary-address": "1", 
"address": [ 
"address-id": "1", 
"customer-address": "192.0.2.2" 
] 
} 
i 
"ipv6": { 
"local-address": "2001:db8::1", 
"prefix-length": 64, 
"address-allocation-type": "static-address", 
"“primary-address": "1", 
"address": [ 
"address-id": "1", 
"customer-address": "2001:db8::2" 
] 
/ 
} 


outing-protocols": { 
"routing-protocol"': [ 
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Dto e VERUM 
"type": "ietf-vpn-common:direct" 


} 
tee 
{ 
Faltele ee CASS 
"interface-id": "1/1/1", 
"description": "Interface DATA to eNODE-B", 
"vpn-network-access-type': "“ietf-vpn-common:point-to-point", 
"vpn-instance-profile": "simple-profile", 
"status": ( 
"admin-status": { 
"status": "ietf-vpn-common:admin-up" 
} 
"connection": { 
"encapsulation": { 
"type": "“ietf-vpn-common:dotiq", 
dotua, 
xovillansdd a2 
} 
} 
n 
"ip-connection"': { 
pv T 
"local-address": "192.0.2.1", 
"prefix-length"': 38, 
"address-allocation-type": "static-address", 
"static-addresses": { 
"primary-address": "1", 
"address": [ 
"address-id": "1", 
"customer-address": "192.0.2.2" 
} 
] 
} 
1m 
SR ower NET 
"local-address": "2001:db8::1", 
"prefix-length": 64, 
"address-allocation-type": "static-address", 
"“primary-address": "1", 
"address": [ 
"address-id": "1", 
"customer-address": "2001:db8::2" 
} 
] 
} 


"routing-protocols": { 
"routing-protocol"': [ 


Voie oe Ta 
"type": "ietf-vpn-common:direct" 
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Figure 34: Create VPN Network Access 


A.2. Loopback Interface 


An example of a loopback interface is depicted in Figure 35. 


"ietf-13vpn-ntw:vpn-network-accesses": ( 
"vpn-network-access"': [ 


"id": "vpn-access-loopback", 

"interface-id": "Loopback1", 

"description": "An example of a loopback interface.", 
"vpn-network-access-type"'": "ietf-vpn-common: loopback", 


a SitatUSimes { 
"admin-status": { 
"status": "ietf-vpn-common:admin-up" 


} 


"ip-connection"': { 

"ipv6": { 
"local-address": "2001:db8::4", 
"prefix-length": 128 


Figure 35: VPN Network Access with a Loopback Interface (Message Body) 


A.3. Overriding VPN Instance Profile Parameters 


Figure 36 shows a simplified example to illustrate how some information that is provided at the 
VPN service level (particularly as part of the 'vpn-instance-profiles') can be overridden by 
information configured at the VPN node level. In this example, PE3 and PE4 inherit the 'vpn- 
instance-profiles' parameters that are specified at the VPN service level, but PE1 and PE2 are 
provided with "maximum-routes" values at the VPN node level that override the values that are 
specified at the VPN service level. 
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"ietf-13vpn-ntw:vpn-services": { 


"vpn-service": [ 
"vpn-id"': "override-example", 
"vpn-service-topology": "ietf-vpn-common:hub-spoke", 


"vpn-instance-profiles"': { 
"vpn-instance-profile": [ 


"profile-id': "HUB", 

"role": "ietf-vpn-common:hub-role", 
"local-as': 64510, 

"rd-suffix"': 1001, 
"address-family": [ 


"address-family": "ietf-vpn-common:dual-stack", 
"maximum-routes": [ 
( 
"protocol": "“ietf-vpn-common:any", 
"maximum-routes": 100 
} 
] 
} 
] 
m 
( 
"profile-id": "SPOKE", 
"role": "ietf-vpn-common:spoke-role", 
"local-as": 64510, 
"address-family": [ 
"address-family": "ietf-vpn-common:dual-stack", 
"maximum-routes": [ 
"protocol": "ietf-vpn-common:any", 
"maximum-routes": 1000 
} 
] 
} 
] 
} 


"vpn-nodes" : { 
"vpn-node": [ 


"vpn-node-id": "PET", 

"ne-id": "pel", 

"router-id': "198.51.100.1', 

"active-vpn-instance-profiles": { 
"vpn-instance-profile": [ 


"profile-id': "HUB", 
Mod TE98:51765190P5171:0 0/195 
"address-family": [ 


"address-family'": 
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"ietf-vpn-common:dual-stack", 
"maximum-routes": [ 


( 
"protocol": "ietf-vpn-common:any", 
"maximum-routes": 10 
} 
] 
} 
] 
} 
] 
} 
m 
( 
"vpn-node-id"': "PE2", 
"ne-id": "pe2", 
"router-id': "198.51.100.2", 
"active-vpn-instance-profiles"': { 
"vpn-instance-profile": [ 
"profile-id": "SPOKE", 
"address-family": [ 
"address-family'": 
"ietf-vpn-common:dual-stack", 
"maximum-routes": [ 
( 
"protocol": "ietf-vpn-common:any", 
"maximum-routes": 100 
} 
] 
} 
] 
} 
] 
} 
a 
{ 
"vpn-node-id"': "PES", 
"ne-id": "pe3", 
"router-id': "198.51.100.3", 
"active-vpn-instance-profiles": { 
"vpn-instance-profile": [ 
"profile-id": "SPOKE" 
] 
} 
ps 
( 


"vpn-node-id': "PE4", 

rre Joss "pe4", 

"router-id': "198.51.100.4", 

"active-vpn-instance-profiles": { 
"vpn-instance-profile": [ 


"profile-id": "SPOKE" 
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Figure 36: VPN Instance Profile Example (Message Body) 


A.4. Multicast VPN Provisioning Example 


IPTV is mainly distributed through multicast over the LANs. In the following example, PIM - 
Sparse Mode (PIM-SM) is enabled and functional between the PE and the CE. The PE receives 
multicast traffic from a CE that is directly connected to the multicast source. The signaling 
between the PE and the CE is achieved using BGP. Also, the RP is statically configured for a 
multicast group. 


4----------- + ------ + +------ + 4R----------- + 
| Multicast |---| CE |--/--| PE |----| Backbone | 
| source | +------ + +------ + | IP/MPLS | 


Figure 37: Multicast L3VPN Service Example 
Figure 38 illustrates how to configure a multicast L3VPN service using the L3NM. 


First, the multicast service is created together with a generic VPN instance profile (see the excerpt 
ofthe request message body shown in Figure 38). 
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"ietf-13vpn-ntw:vpn-services": { 
"vpn-service": [ 


"vpn-id': "Multicast-IPTV", 


“vpn-description": "Multicast IPTV VPN service", 
"customer-name": "a-name", 
"vpn-service-topology": "ietf-vpn-common:hub-spoke", 


"vpn-instance-profiles"': { 
"vpn-instance-profile": [ 


"profile-id": "multicast", 
"role": "ietf-vpn-common:hub-role", 
"local-as": 65536, 
"multicast": { 
Tip 
"rp-group-mappings": { 
"rp-group-mapping"': [ 
Paola s | 
"rp-address": "203.0.113.17", 
"groups": ( 
"group": [ 
Pais! 3 ll, 
"group-address": "239.130.0.0/15" 


] 
} 
} 
] 


"rp-discovery": { 
"rp-discovery-type": "ietf-vpn-common:static-rp" 


Figure 38: Create Multicast VPN Service (Excerpt of the Message Request Body) 


Then, the VPN nodes are created (see the excerpt of the request message body shown in Figure 39). 
In this example, the VPN node will represent VRF configured in the physical device. 
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"ietf-13vpn-ntw:vpn-node": [ 


"vpn-node-id': "500003105", 
"description": "VRF-IPTV-MULTICAST", 
"ne-id': "198.51.100.10", 
"router-id': "198.51.100.10", 
"active-vpn-instance-profiles": { 
"vpn-instance-profile": [ 


"profile-id": "multicast", 
"rd": "65536:31050202" 


Figure 39: Create Multicast VPN Node (Excerpt of the Message Request Body) 


Finally, create the VPN network access with multicast enabled (see the excerpt of the request 
message body shown in Figure 40). 
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"ietf-13vpn-ntw:vpn-network-access": { 


zu 8-3 AAT 

"description": "Connected-to-source", 
"vpn-network-access-type": "ietf-vpn-common:point-to-point", 
"vpn-instance-profile": "multicast", 


"status": ( 
"admin-status": { 
"status": "ietf-vpn-common:admin-up" 


"ip-connection"': { 
"ipv4": { 
"local-address": "203.0.113.1", 
"prefix-length": 38, 


"address-allocation-type": "static-address", 
"static-addresses": { 
"primary-address"': "1", 


"address": [ 


saddinesscadis: esl 
"customer-address": "203.0.113.2" 


] 
} 
} 


outing-protocols": { 
"routing-protocol': [ 


} 


Pales epus 

"type": "ietf-vpn-common:bgp-routing", 

"bgp": ( 
"description": "Connected to CE", 
"peer-as": "65537", 
"address-family": "ietf-vpn-common:ipv4", 
"neighbor": "203.0.113.2" 

} 

} 
] 


"service": { 
"pe-to-ce-bandwidth": "100000000", 
"ce-to-pe-bandwidth": "100000000", 


"mtu": 1500, 

"multicast': { 
"access-type'": "source-only", 
"address-family": "ietf-vpn-common:ipv4", 
"protocol-type": "router", 
"pim": 


"hello-interval': 380, 
"status": ( 
"admin-status": { 
"status": "ietf-vpn-common:admin-up" 
} 


} 


} 
} 
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Figure 40: Create VPN Network Access (Excerpt of the Message Request Body) 
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